Hi James, Based on the time frame suggested (60 months) I agree with the Committers emeritus. 5 years is a good time span to participate and contribute in any form to the community at least once.
One thing I am not sure about is that should we notify the qualified committers about the let-go of committer rights and ask if they want to continue contributing or not - If the number of such committers is more then this doesn't sound practical to me and the approach of rejoining them once they come back sounds right as suggested. 60 months Regards, Bharath Lead Implementation Analyst | Mifos Initiative Skype: live:cbharath4| Mobile: +91.7019635592 http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> On Sat, Jul 8, 2023 at 12:07 AM James Dailey <[email protected]> wrote: > Devs - > > I would like first to DISCUSS and then subsequently to VOTE on the idea of > moving some Fineract Committers to the "emeritus" status. I will keep the > discussion open for three days, then vote open for three days. This has > been briefly discussed before, but I want to be more explicit. > > My idea or proposal is that anyone who has NOT participated on the > listservs of fineract (dev, security, private) AND has not made any > contribution to Jira, wiki, documentation, or code for at least 60 > months (5 years) becomes, automatically, and at the discretion of the PMC, > "emeritus". > > When in Emeritus status, the person will not have Committer rights to > github. > When said person returns, they may rejoin and be given immediate access to > the github as long as they abide by our norms and rules. (these may have > evolved over time, so it will be important for them to be given some > orientation by the currently active contributors in the project) > > My argument for this is that we have a lot of inactive people who have > committer access, and this is not a good practice in achieving our goal of > an active and transparent community - where we know who is involved, who > can help with a code change or review, and also creates a potential (albeit > small) security risk. It at least seems like a potential issue to those > doing audits of process. > > ***I would like any and all counter arguments to be heard**. * If there > are none, we will move to a vote. If there are significant objections, we > will seek to revise before I go to a vote, or I may change my mind. ***So, > please articulate why you agree or disagree with this idea**. * > > Thanks > - James > >
