Great starting points! I agree w/ JB's point that some of this should be private@ discussion. I am keeping my comments to things that I think everyone on dev@ should be part of.
For all mentions of ASF policy: we should have our own link to the relevant policy. It is hard enough for us to find ASF policy docs, and almost impossible to know whether docs exist, whether you have the "right" ones or "all" of them. On Tue, Jan 23, 2018 at 8:43 AM, Ismaël Mejía <[email protected]> wrote: > > * Code of conduct > +1 to link to ASF policy * Proposal process > +1 to link to ASF policy "it has to happen on list" Design docs fall into the same category and coding and code review: use the right tool. It would help to describe our practices and tools. I want to see comments like: "let's move this from a PR to dev@" and "this needs a design doc" and "these doc comments should move back to dev@" and also "this is small enough you can just code it up". > * Governance model > I think the biggest gaps we have are in governance of governance. ASF policies establish about half of what is necessary, notably missing the need for expiry and renewal. Mostly, we should be transparent about what the PMC does and how often, etc. Threads on private@ of course are private for a reason, but they should be private without seeming arbitrary or mysterious. * Contribution policies - Avoid CI issues: Extremely long tests that break for unrelated > issues should be minimized > +1 and this is in crisis IMO. Since "hope is not a strategy" I think we need to cut scope and rebuild in a way where signals don't clobber each other. > - Review of pull requests should take less time than the current > average (We should probably get some stats on this / define what is an > acceptable review time and what is the expected process when a > reviewer is not active). > +0.5 I think we should reduce latency for response and document policy so newcomers feel empowered to "ping". -1 to any lower review standards. Discussion on a PR should build community. You can also issue a PR to a PR and discuss *that* PR to show even more outreach. There is no conflict between high quality code and friendly community. Anyhow for me, I love to write, read, and discuss code :-) - We should add the previously discussed policy on stale PRs to the > contribution guide. > +1 - Encourage a well balanced distribution of reviews, there are some > committers that do many reviews, and of course this is not ideal. > +1 can we pull numbers or dashboard review load over time? - Give priority for reviews / help to new contributors that are > starting in the project or to critical fixes. > +1 especially new contributors - ... commitership/PMC status... > https://flink.apache.org/how-to-contribute.html#how-to-become-a-committer +1 to link to ASF policy, maybe add something, maybe not. Kenn
