I'm +1 on all of those points, except "Drive standards for that component" and possibly "Manage issues related to that component." That is, the secretarial things, but not the authority things.
My fear here is that these kind of "authority appointments" will lead to reduced consensus and community. Helping release management, issue triaging, and other bureaucratic tasks sounds great. But if this person is given more authority than any other community member to make decisions...that seems to go against the Apache Way. We do have experts on each product, language, and system; and hopefully members of the community generally defer to their expertise. But the Apache Way is to find consensus with the whole community, not to dictate or appoint a person to have overruling authority. Even if the "lead" is voted on, that allows a majority to dictate things, not to mention all the legitimacy problems of political electoral systems. Apache Consensus isn't democracy or majority rule, it's everyone working together to find a solution that makes everyone as happy as possible, not just one person or 51% of people. And if that dictating isn't going to happen, why appoint someone with that power? I know we have some heated discussions. Consensus can be hard. But I think we have a better product for it. Again, I'm a big +1 on all the managerial stuff. Maybe a more appropriate title would be something like "Product Secretary" or "Project Mentor?" On Wed, Nov 13, 2019 at 10:25 AM Gray, Jonathan <jonathan_g...@comcast.com> wrote: > What does this allow us to do that can't already be done today? The main > gain I can think of is helping users find knowledgeable people (which could > volunteer themselves today as part of a collaborative and inclusive > community). There's not anything presently stopping individual committers > from taking greater responsibilities for sections of code, issues, and PRs. > > Jonathan G > > > On 11/13/19, 9:59 AM, "Jeremy Mitchell" <mitchell...@apache.org> wrote: > > I would like to propose the idea of open source component leads for > TP, TO, > TR, TM and TS. I think having a component lead would help with the > following: > > - Help the release manager compile comprehensive release notes for that > component > - Help the release manager determine release scope related to that > component (what to not cherry pick to a release) > - Release candidate testing/validation for that component > - Manage issues related to that component (i.e. apply labels > (component, > type and severity)) and close old/irrelevant issues. > - Develop a first pass roadmap (maybe a roadmap.md file at the root of > the > component?) for that component and potentially create milestones and > facilitate discussion around the roadmap/milestones. > - Clean up old PRs for that component > - Drive standards for that component > > IMO these component leads would probably need the following > qualifications: > > - someone that works with the component on a day-to-day basis and is > obviously very experienced with the component. > - is a committer so they can do things like apply labels, create > milestones, merge PRs, etc. > > Ideally these component leads would represent different companies, > however, > maybe that is a goal and not a requirement at the moment. > > I bring this up because I think having component leads would help the > quality, organization and transparency of the TC project as a whole and > would provide potential contributors with a better vision of where TC > is > headed. > > Thoughts? > > Jeremy > > >
