couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Sun, 02 Jun 2013 18:52:37 GMT

On May 30, 2013, at 14:01 , Noah Slater <nslater@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 <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
View raw message