I agree with Julian: the "Insight" tab of the project is a pretty good indication of activity when it comes to coding. Another one is just looking at the activity of the devlist/private (which is as easy as looking at " lists.apache.org") for non-strictly coding activity, and eventually any of the other "out-of-devlist" communication media project uses - slack/discord/matrix etc. All of those provide some signals - not necessarily quantitative, more of them qualitative and "impression" driven than the health of the project.
The interesting question here is how quantitative (and comparable with other projects) those observations should be, how we are judging them and most importantly - whether those observations and assesment should trigger some actions (and what kind of actions). For me - this is an important thing to understand as a mentor if my role is to help the project graduate, or more to guide the community to do the "right thing" - which might or might not be graduation - and when and how to make those decisions. This is more of a "academic" question for now - which I do not have to deal with now, but I imagine, that by seeing how activity of the project picks (or does not pick) up, how health of the project improves or decline, should be more of an indication of things for mentors rather than singla to action on helping and encouraging people to - for example - work on improving the health by actively reaching out to new contributors etc. When I think of such PPMC -> PMC process, it's great if we can help the PPMC graduate when they achieve the health, activity and governance levels that are considered as "PMC ready", but also how much it should be also at some point of time - if there are no signs of it, maybe it's time to think about dropping out (I guess we have a process for that). Just to give you an example from my other past mentorship roles - with people - I had a case where I had 3 mentees from Outreachy - 2 of them grew a lot and achieved a lot and are now examples of a success of the mentorship programme, but one of them - despite many efforts and active/proactive attempts to improve things and let the person learn and grow, did not work, so we decided (two mentors - after talking to Outreachy and consulting with them) to give the person an honest feedback, that they are better doing some other things, because this would be better for them - we continued the mentorship and programme to the end - but with some small things that would not be enough to complete the programme successfully, so we did not "stop" the program - but we change the goal from "succeed" to "successfully fail". I think one of the most difficult parts of the mentor is to know when to call it quits and when to stop trying to "succeed" - but when to turn this kind of process into "successful failure". I wonder what other think about it and how things worked in the past and whether this is something that others struggle with. J. On Mon, Jan 26, 2026 at 8:50 AM Julian Hyde <[email protected]> wrote: > Even though we value ‘community over code’, code is important. So, mentors > should keep an eye on coding velocity — how frequent are commits, how many > distinct individuals are committing, arrival and review rate of PRs, and > whether work is happening in main branch or somewhere else. The GitHub > reports cover most of these metrics. > > Change in coding velocity is often the first sign that something > significant has happened in the project’s ecosystem — such as that a > company that employs several committers has shifted its focus away from the > project. It is important that mentors are aware of that context, and > unfortunately PPMC members don’t usually provide it. > > Julian > > > > On Jan 25, 2026, at 2:07 PM, Justin Mclean <[email protected]> > wrote: > > > > Hi, > > This month, I want to talk about something we often notice in the > Incubator but rarely discuss directly: how projects keep up their momentum > between releases. > > Podlings usually don’t fail all at once. Instead, activity often slows > gradually. There are fewer reviews, slower discussions, and longer waits > for decisions, long before any release delays appear. Still, long gaps > between releases aren’t always a bad sign. Some healthy communities can > stay active and involved even if they don’t release often. > > I’d like to hear from mentors and IPMC members about what has worked > well for you in practice, such as: > > - What kinds of activity you look for between releases to gauge whether > a podling is still healthy > > - How do you tell the difference between a quiet phase and genuine > stagnation > > - Early signals that have prompted you to step in, or to deliberately > step back > > - Ways you have helped maintain momentum without becoming a bottleneck > > The aim isn’t to force projects into strict release schedules. Instead, > let’s share our experiences and patterns to better support podlings as they > develop. > > Feel free to reply with examples, counter-examples, or even times when > the signals turned out to be misleading. > > Thanks, > > Justin > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
