> On Oct 14, 2016, at 7:46 AM, Jean-Baptiste Onofré <[email protected]> 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. Dan > > 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 ! > Regards > JB > > 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: [email protected]. >> 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 ? >> >> Regards >> JB > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
