Agreed Rob. I didn't mean to imply that these "component leads" would have more power. Rather that they'd facilitate and lead discussions (on standards or roadmaps or whatever), be a point of contact for a release manager, and keep things generally tidy and transparent in regard to that component. That also means making sure email discussions are resolved and not left hanging forever.
Any yes, jonathan, there's nothing stopping anyone from doing this today but I don't see any of these things being done so maybe a different approach would help. Maybe component lead is not the right term? On Wed, Nov 13, 2019 at 10:45 AM Robert O Butts <[email protected]> wrote: > 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 <[email protected] > > > 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" <[email protected]> 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 > > > > > > >
