One of the advantages I see with a more formal process is (like Kafka KIPs) is that it levels the playing field a bit and sets some ground rules for working together. In a way it can help encourage contributions by making it clear what is expected of potential contributors.
We have a design review process today that is not as formal as KIPs, but is somewhat heavier than the one you describe. Maybe we could tweak our current one by starting to do design reviews separately from PRs. i.e., for anything that meets our 'design review' criteria, do that on the dev list or in a separate issue, and keep the PR focused on code-level stuff. That way we don't end up trying to do both at once. And it makes it easier to start talking about design before the code is ready, which would be better. On Wed, Jan 2, 2019 at 6:10 PM Julian Hyde <jh...@apache.org> wrote: > 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 > >
