| Re: [eclipse.org-architecture-council] Encourage removal of inactive committers |
Thanks for starting this discussion. I like all of your ideas. I don't think that we need a change to the EDP to make any of it work.I'm a little concerned about automatically labeling people as inactive. Currently we only monitor activity in Git commits. Specifically, the only means that we currently have to determine whether or not somebody is active is by having them listed as either the author or as an "also-by" on Git commits. We don't track, for example, whether or not somebody is helpful in reviewing/merging pull/merge/review requests or is actively helping contributors in mailing lists (or wherever). IMHO, we need to have access to better metrics before we can make any sort of judgement about whether or not a committer is active.I have mixed feelings about whether or not it makes any sense to be a committer if you don't need the superpowers that come with being a committer. That is, I want to be careful about how we approach removing committer status from people just because they don't need it. One can, for example, be super useful in a mailing list without having committer status; if that's the only (super valuable) thing that an individual does, do they need to be a committer? Is being a committer as status actually valuable?We do need a means of making it easier for project leadership to identify committers who are candidates for retirement based on the metrics that we do have available.I really like the idea of a periodic message from the system to the mailing list that at least reminds the team that they have an obligation to keep their committer list current.FWIW, from my experience the biggest challenge is for those projects that cannot run successful elections because they don't have enough active committers that participate (some smaller projects have only two or three committers and if only one of them doesn't vote, you're done). When elections fail, that triggers a process by which the EMO first works with the project team to mitigate the issue; and that failing, the EMO works with the PMC to declare the project dysfunctional, granting the project leadership chain the ability to add/remove committers as they see fit.It's worth noting that the Architecture Council is actually part of the EMO and is -- by extension -- part of the project leadership chain. We haven't traditionally involved the AC in mitigation activity, but would be happy to sort out a means of engaging if members think that they can bring value to the process.WayneOn Fri, Nov 19, 2021 at 9:42 AM Mickael Istria <mistria@xxxxxxxxxx> wrote:_______________________________________________Somehow, from the EDP, one could interpret that a project that doesn't seem to actively maintain the list of active committers is not acting as defined by the EDP and is dysfunctional, so PMC and EMO could already act upon it.So overall, I agree the EDP maybe doesn't need a more explicit change.But tools to encourage projects in properly maintaining an "up-to-date" list of committers would really be helpful, and be in the best interest of the project, according to what's defined in the EDP and everyone has agreed with when contributing to Eclipse project (just to clarify that it's not just my opinion here, but really what the EDP already states).
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
--_______________________________________________Wayne Beaton
Director of Open Source Projects | Eclipse Foundation
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council