It’s really hard to say no to a contribution when someone has put in a significant amount of work.
The following approach is simple and works really well: Before you start work, log a case, describing the problem. When you have some ideas about design, add those to the case. When you have a code branch, add its URL to the case. And so forth. At any point in the proceedings, people can chime in with their opinions. In my opinion, a formal “design review” process is not necessary. Just build consensus iteratively, by starting the conversation early in the process. Julian > On Jan 2, 2019, at 12:37 PM, Gian Merlino <g...@apache.org> wrote: > > In this particular case: please consider the PR as a proposal. Don't feel > like just because there is code there that takes a certain approach, that > the approach is somehow sacred. I had to implement something to crystallize > my own thinking about how the problem could be approached. I won't be > disappointed if, as a community, we decide a different direction is better > and the code all gets thrown away. That's one of the reasons that I removed > the 0.14.0 milestone that was added to the patch. (I don't want to rush it, > nor do I think that's a good idea.) > > In general: Sounds like we could do with some more formalization around > what a proposal looks like, which sorts of changes need one, and when in > the dev cycle it is appropriate. FWIW I think Kafka's process is more or > less fine, and would be okay with adopting it for Druid if people like it. > Right now our standards for what requires a "design review" are very > similar to the Kafka community standards for what requires a KIP, so we > have some familiarity with those concepts. However we don't separate PR > review and proposal discussion as strictly as they do, which seems to be > the foundation for the feeling of exclusion that is being felt here. > > Separately: I just redid the description on > https://github.com/apache/incubator-druid/pull/6794 to be more proposal-y. > I followed the KIP style: > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals. > Please refresh the page and see if it looks more useful. > > Gian > > On Wed, Jan 2, 2019 at 10:52 AM Julian Hyde <jh...@apache.org> wrote: > >> Slim, >> >> I agree with your points that offline development is bad for community. >> But I don’t think you need much mentor help. You have raised valid issues >> and the Druid community needs to decide what its development practices >> should be. >> >> Julian >> >> >>> On Jan 2, 2019, at 10:29 AM, Slim Bouguerra <bs...@apache.org> wrote: >>> >>> Hello everyone and hope you all have very good holidays. >>> >>> First, this email is not directed on the author or the PR >>> https://github.com/apache/incubator-druid/pull/6794 it self, but i see >>> this PR as a perfect example. >>> >>> One of the foundation of Apache Way or what i would simply call open >> source >>> community driven development is that "Technical decisions are discussed, >>> decided, and archived publicly. >>> developpement" >>> Which means that big technical changes such as the one brought by #/6794 >>> should have started as a proposal and round of discussions about the >> major >>> changes designs not as 11K line of code. >>> I believe such openness will promote a lot of good benefits such as: >>> >>> - ensures community health and growth. >>> - ensures everyone can participate not only the authors and his >> co-workers. >>> - ensures that the project is driven by the community and not a given >>> company or an individual. >>> - ensures that there is consensus (not saying 100% agreement;) however it >>> means that all individuals will accept the current progress on the >> project >>> until some better proposal is put forth. >>> >>> Personally such BIG offline PR makes me feel excluded and doesn't give >> me a >>> sense that i belong to a community at all. >>> >>> To prevent such off list development i think as a Druid Community we need >>> to stick to the apache way “If it didn’t happen on the mailing list, it >>> didn’t happen.” >>> >>> I would appreciate if some of the Apache mentor help with this. >>> Thanks >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org >> For additional commands, e-mail: dev-h...@druid.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
