> On Oct 14, 2016, at 7:46 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> I think we agreed on most of the points. We also agreed that points 4 & 5
> should be a best effort and not "enforced”.
4 and 5 are really just needed when any “significant change” are part of the
discussion. Things like whitespace and typos and such don’t need to be pushed
back to the list. However, if you run into something that “just doesn’t work”,
that should be reflected back. As an example, my first GridFS PR, when
Eugene basically stated that the entire structure needed to change, (from doing
everything in the Source to splitting into a simpler Source and a ParDo) that’s
something that should have been brought back to the list in a summary.
BTW: this ALSO goes for anything in google docs. Some of the proposals are
in google doc form so any changes/discussions at google are also not “at
Apache”. In looking at the proposed workflow, I also think when the proposal
is accepted/complete/whatever, the google doc needs to be exported to something
and attached to the JIRA so it is properly archived at Apache. Personally,
I’d prefer limiting the use of google docs, but I do understand that having the
diagrams can be important. Not sure how to deal with that in email. One
thing the incubator does with proposals from their wiki is require the full
TEXT of proposals be copied into the email (so searchable and also clear what
version is be being looked at) with the link to the full doc.
> If there's no objection, I will create the review mailing list and update the
> github integration configuration.
> Thanks all for your comments and feebacks !
> On 10/06/2016 01:53 PM, Jean-Baptiste Onofré wrote:
>> Hi team,
>> following the discussion we had about technical discussion that should
>> happen on the mailing list, I would like to propose the following:
>> 1. We create a new mailing list: rev...@beam.incubator.apache.org.
>> 2. We configure github integration to send all pull request comments on
>> review mailing list. It would allow to track and simplify the way to
>> read the comments and to keep up to date.
>> 3. A technical discussion should be send on dev mailing list with the
>> [DISCUSS] keyword in the subject.
>> 4. Once a discussion is open, the author should periodically send an
>> update on the discussion (once a week) containing a summary of the last
>> exchanges happened on the Jira or github (quick and direct summary).
>> 5. Once we consider the discussion close (no update in the last two
>> weeks), the author send a [CLOSE] e-mail on the thread.
>> WDYT ?
> Jean-Baptiste Onofré
> Talend - http://www.talend.com
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com