couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Thu, 30 May 2013 12:01:00 GMT
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 <nslater@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 <jan@apache.org> wrote:
>
>>
>>
>> On 22.05.2013, at 15:44, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>
>> > On Wed, May 22, 2013 at 11:32 AM, Dirkjan Ochtman <dirkjan@ochtman.nl>
>> wrote:
>> >> On Tue, May 21, 2013 at 10:26 PM, Jan Lehnardt <jan@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message