Thinking [EVENTS] and user support might also be good merged into [COMMUNITY] or [COMDEV].
Some things I think fall under community outreach/development: * Organising events, meetups, hackathons, conferences * Managing trademarks and branding issues * Providing "meet-up-in-a-box" and standard slide decks * Shepherding the erlang@ list, and user@ list * Managing some sort of CouchDB University * Interacting with StackOverflow, Google+, etc communities On 30 May 2013 12:52, Noah Slater <[email protected]> wrote: > I've been organising my task list, and I've merged PKG and RELEASE into > one team called PM. PM here being short for Product Management. Think it > makes sense to group these things together. Hoping to get Brian Green > involved in this too. > > > On 22 May 2013 14:51, Jan Lehnardt <[email protected]> wrote: > >> >> >> On 22.05.2013, at 15:44, Benoit Chesneau <[email protected]> wrote: >> >> > On Wed, May 22, 2013 at 11:32 AM, Dirkjan Ochtman <[email protected]> >> wrote: >> >> On Tue, May 21, 2013 at 10:26 PM, Jan Lehnardt <[email protected]> wrote: >> >>> So far. >> >> >> >> There are some things here I like, and some I don't like that much. >> >> >> >> I like the emphasis on do-ocracy, and the encouragement for >> >> non-committers to just do stuff (and get elected as a committer soon >> >> thereafter). Or, rather more general, I like all the stuff where you >> >> describe opportunities and encouragements and welcoming and shit that >> >> can be done. >> >> >> >> <ranting> (with a little hyperbole, maybe) >> >> >> >> Then, the document goes off and just undoes all of that by boxing >> >> everything into tags and teams. Those bits make me just want to revert >> >> to my grumpy rant from March's Goals for 2013 thread. This project has >> >> way too few active people working to require this much process (most >> >> of the tags and the teams); it's just process that maybe makes us feel >> >> good, but doesn't actually seem accomplish anything. >> >> >> >> Yes, having a short list of people who are interested in specific >> >> areas of the project would be good. But is "[PROPOSAL] Pulling >> >> INSTALL.* into the docs" really a better subject than just "Pulling >> >> INSTALL.* into the docs"? Do we need to carefully delineate every >> >> mailing list thread into something that has a specific timeout rules? >> >> >> >> I'll posit that if we were a do-ocracy, if we do apply EAFP (which I'm >> >> all for!), we don't need all of that stuff. We push stuff forward when >> >> we have the chance. When we go a little too far in our enthousiasm, we >> >> generally have ways of reverting without much effort. And it would >> >> still be useful for new contributors to know that, if the docs suck in >> >> some specific area, or if they have an event they want to organize, >> >> there are a few people they should talk to who generally know what's >> >> going on in that area. And we might call those teams. But I don't >> >> think we should get mired too much in delineating Boundaries and >> >> Processes. >> >> >> >> And that concludes yet another Grumpy Rant,s >> >> >> >> Dirkjan >> > >> > I'm agree with all of that. >> > >> > Anyway ather than team maybe we can just consider tags as a way to >> > notify other what's going on and not as teams. I think teams are >> > prematured right now. We will have a lot of overlaps between people >> > anyway. I'm +1 for having a bunch of supported tags. Will see how it >> > works in real life anyway since it's all to people to use them or not. >> > >> > One practical thing I see to tags is that it can also improve their >> > referencing and help us to build some kind of relaxed knowledge base. >> >> >> That summarises my intent. I'm glad we are on the same page. :) >> >> Jan >> -- >> >> > > > -- > NS > -- NS
