On May 30, 2013, at 14:01 , Noah Slater <nsla...@apache.org> wrote: > 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
I think user support and managing events should be two groups. Of course whenever there *is* an event, we want to tell the community, but I don’t think putting all these things into a single bucket (which is, note, just a virtual bucket on top of dev@) doesn’t buy us much. Jan -- > > > > On 30 May 2013 12:52, Noah Slater <nsla...@apache.org> 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 <j...@apache.org> wrote: >> >>> >>> >>> On 22.05.2013, at 15:44, Benoit Chesneau <bchesn...@gmail.com> wrote: >>> >>>> On Wed, May 22, 2013 at 11:32 AM, Dirkjan Ochtman <dirk...@ochtman.nl> >>> wrote: >>>>> On Tue, May 21, 2013 at 10:26 PM, Jan Lehnardt <j...@apache.org> 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
