new ports and maintainer

[Ryan Schmidt]

On Jul 25, 2014, at 9:31 AM, Mihai Moldovan wrote:
> 
>> I agree we have a problem with maintainers disappearing and it taking some time for us to notice and react. But we do have a port abandonment procedure, and I would instead focus on improvements to that procedure, and better maintainer education. For example, we could improve the port abandonment procedure to include all other ports by the same maintainer; that's how I usually file the tickets anyway. We could mention in the guide what our expectations are when a maintainer no longer has the time or interest for maintaining. We could recommend the addition of openmaintainer when someone assumes maintainership, especially for non-committers. We could include information on how to retire in the email that management sends to approved committers.
> 
> That's a good idea, as long as openmaintainer stays a recommendation and not a
> requirement.

Right. I just think we got too much in the habit of encouraging new contributors to become a newly submitted port's sole maintainer, without adequately educating them about the responsibilities that entails. We should improve on that, and also encourage the addition of openmaintainer so that submitters who agree to maintain but don't stick around don't hinder us later.


>> There was a recent discussion about manually sending out a maintainer survey, but it would be nice not to bother maintainers who are clearly active. We could develop an automated way to survey maintainers about their continued involvement. An automated system could estimate a maintainer's level of current involvement in the project by checking for tickets filed, commits made, mailing list posts sent, and only send such emails periodically to developers who have not been active in the last 3 months, say. A maintainer could reply to such an email to indicate whether they are still active; a "no" response or multiple unanswered emails could trigger the port abandonment procedure, e.g. by automatically filing a port abandonment ticket or even by automatically removing them as maintainer of their ports.
> 
> Manually sending out mails and processing answers is not going to fly. Not with
> the huge maintainer list there is.
> 
> Automatically determining inactive maintainers by your outlined criteria and
> sending out surveys on the other hand sounds good. At the same time, replies
> will also have to handled automated, I cannot believe one or several people
> could handle the burden of keeping track of answering or not answering
> maintainers. Compared to just updating a timestamp, this is far worse busywork.
> 
> I like that idea very much though and think it's the way to go. There's just one
> problem with it.
> 
> It sounds complicated to write scripts doing of all this. You'd have to hook
> into the mailing list, query the Trac database backend directly (the website has
> no means of searching for comments made by a specific user), keep a list of sent
> mails, update that on replies and decide and implement timeout measures.
> 
> This probably could qualify as a GSoC project, alongside adding an option to
> Trac to be able to search for comments made by a specific address.
> 
> Given MacPorts is understaffed as it is, I don't see something like this being
> implemented, up and running in just a few hours.

My plan for the new web site is that in addition to a page for each port, there should be a page for each maintainer. It would include automated statistics, such as graphs of ports maintained over time, tickets filed, ticket comments, mailing list posts... For committers, it could include a graph of commits.

Once the web site has this data, it could be reduced down to a single indicator of how active the contributor has been lately. We could then do things with that indicator, like sort the list of maintainers by activity, or have the web site backend send out the emails to inactive contributors, store the results, display them on the site too...