Thanks everyone for interacting with this thread. The fact that i, Roman, Jihoon and others in the past (FJ https://groups.google.com/forum/#!msg/druid-user/gkUEsAYIfBA/6B2GJdLkAgAJ) raised this point indicates that PRs without a proposal are indeed an issue and we need to solve it.
Something Similar to KIP maybe called DIPs is fine with me. What i strive to see is the following: [Step 1] formalize what is the kind of work that needs a formal Proposal, I think Roman and Jihoon has already covered that pretty well. am +1 on that. https://lists.apache.org/thread.html/9b30d893bdb6bb633cf6a9a700183ffb5b98f115330531a55328ac77@%3Cdev.druid.apache.org%3E I am strongly in favor of the separation of Proposal Review and (later) Code review PRs. My main reasons: Most importantly code reviewing will introduce lot of noise and will ultimately make the GitHub page unreadable. Avoid overlapping of work. Once code is written hard to think abstract. Separate page for Design review later can always be used it as a Design document that is readable and code free-ish. As i said the goal of this first round is to see if the community agree about such change, then make the process of design more inclusive thus other contributors can submit a counter proposals. [Step 2] IF everybody agree about that point Step 2 is to define which medium is used to Publish a primitive form of a CODE FREE Abstract Proposal containing at least the following bullet points. - The problem description and motivation - Overview of the proposed change - Operational impact (compatibility/ plans to upgrades) public API changes, configuration changes, algorithm, and so on - Expected benefits and drawbacks - Rationale and alternatives - Estimate Time to Deliver if possible. The way i think this can be is a Github issue where member of the community will interact via comments and the author will be updating the description in the light of comments provided by the community. During and near the end of the design discussions the author/s can start writing POCs to help guide the review process this naturally will be a Pull request with actual code. *Now the most important thing is that we need to agree that any work that does not align with this formal process will be ignored and the author will be asked to start with a DIP* *That is what i meant with “If it didn’t happen on the mailing list, it didn’t happen.”* Thanks and happy coding! On Wed, Jan 2, 2019 at 6:47 PM Gian Merlino <g...@apache.org> wrote: > 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 > > > > >
