Side note: I've done some wiki gardening to clean things up, but there's lots to do... Feel free to engage...
Our desire to make the Committer Survey shorter was well received. Wayne promised to provide the council with the draft list of questions to solicit feedback next week.
What does "inactive"/"active" mean? Contribution in forms that are not Git commits.
Criteria for retire a committer mirrors criteria for becoming a committer. Becoming a committer requires a demonstration of merit/reputation. Staying a committer requires ongoing maintenance of the reputation.
From the EMO's perspective, our primary concern is committers who have abandoned their accounts. These accounts are a security risk.
Fully automating retirement not good. The Git commit record is only one source of reputation. Committers may contribute in other ways (e.g., issue triage).
Question: If not committing, why do people need committer status.
Answer: Access to committer benefits: badges, committer receptions, other forms of recognition.
Wayne has a blog post in draft that includes a short discussion of how to retire committers (based on what some projects, including the Eclipse Project, do as a matter of practice):
> The practice that many project leads follow is to use the PMI to determine which committers are inactive and then post the names of inactive committers on the project's main communication channel (usually the dev-list or an issue) with instructions for those individuals to respond if they feel that they should retain committer status (a committer's response on the dev-list can be considered an indication that the committer is still active). Set a reasonable deadline and retire everybody who does not respond when that date passes. The sweet spot is four weeks, and never during the summer.
The new metrics dashboard provides us with data for more channels (e.g., issues, discussions, mailing lists) to help us identify candidates for retirement. The EMO has an opportunity to do more to help project leads identify candidates.
We discussed potentially having more fine-grained roles. Wayne described the three levels of roles: committers, project leads, contributors, and how within the committer team, additional roles can be created. Technical leads, for example, can emerge from a project team, but only have as much power power as the committers grant.
The CODEOWNERS feature in GitHub is consistent with the EDP. The feature can only be used to manage privileges of committers (you can't add privileges for people who are not committers). The path to be granted privileges must conform to the open source rules of engagement and be documented. We need to add this to the handbook; we have created an [issue](
https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/issues/200).
"Friends of Eclipse" has been retired.
The issue regarding project sponsorships has been open for a while. The EMO has talked about this internally over the last month. Wayne's expressed a personal opinion that he believes that connecting sponsors directly to committers should be relatively easy (turning this option on is not currently supported). Sponsorships funneled through working groups are also relatively easy (working group committees decide who gets the funds), but heavyweight (a working group is required). Sponsorships to projects is relatively hard: projects are not legal entities, so the EF has to receive the funds; nobody wants the EF to be the decider of how funds are collected, so we need to sort out a means for doing this. We have some ideas that Wayne will try to present in a (near) future meeting.
Wayne has opened an [issue](
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/7265) to change the name of the mailing list.
