couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 17:47:44 GMT
(I would also point out that we're not expected to use the ML as the
default place to go to to find out information about the project. We can
search the archives, for sure, but that should be a last remote. Important
information, decisions, etc, should be taken out, and put in the code, in
JIRA, on the wiki, on the site, etc. The ML is our primary *communication*
tool. Nothing more.)


On 15 March 2013 17:22, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:

> On Fri, Mar 15, 2013 at 9:47 AM, Noah Slater <nslater@apache.org> wrote:
>
> > Note to the list. I am flagging this thread as something to distill into
> > our community guide. I think it's important we talk about this somewhere
> > that is a little less easy to loose than a mailing list post.
>
>
> I suspect that you've hit the kernel of why a subset of potential
> contributors to the project feel like the everything-must-be-on-the-ML
> requirement is onerous.
>
> While I fully recognize that the infrastructure to do what I'm about to
> describe doesn't exist and wouldn't be a trivial project to create, it
> sounds like what is really wanted is some sort of feed aggregation.
>  Something like:
>
> - An ASF project has an official per-project feed that is
> committer-required (similar to the current ML subscription requirement)
> - External tools like github can have their feeds piped directly into the
> official ASF feed for the project
> - Things like facebook and google+ can have community curators that tag
> things as needing to show up in the feed (I presume that you can do things
> like say "I want an RSS feed of everything user X tagged as Y")
> - Similarly, mailing list threads could be included as well, when
> appropriate.
>
> I think that trying to use the ML as a feed aggregation tool, archive and
> discussion forum all at once makes for a bad fit, and is why there has been
> some push back about it.
>
> Eli
>



-- 
NS

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