Hi, I would like to throw out an idea for constructively combating low activity in strongly maintained packages.
Across the Debian package ecosystem team maintainership has been seen as the strongest antidote for package stagnation. This process "just works" because as one team member becomes less active, others tend to pick up the slack, and the package continues on with a healthy life cycle. However, certain areas of the archive remain strongly maintained, and when those packages enter this kind of low activity state, there is no clear or established remedy; thus problems ensue. After time, those packages stagnate, and absent a healthy team spirit, no one can fix it. In fact, often enough potentially helpful volunteers get caught in a type of thermal discouragement beam when trying to contribute. Needless to say, this situation is unfortunate for many. The potentially helpful volunteer gets a dose of negativity and potentially loses interest in the package and after enough of these cases probably Debian altogether, the package stagnates, the existing maintainer takes on a certain level of guilt and frustration, and potential Debian users are lost because of resulting package out-of-dateness qualms. So anyway, enough explanation, on to my proposed solution. Seeing as team spirit has been a quite effective antidote to stagnation, lets go ahead and use that again. Here is my suggested process: 1. An interested volunteer notices that an upstream version of a package has been out for a time frame (perhaps 3 months), but hasn't been packaged by the existing team or maintainer. This defines the low activity state. 2. The interested volunteer files a bug report against the package stating their intent to contribute 3. If an alioth team already exists, the interested volunteer sends an email to ad...@alioth.debian.org with the following information a. Link to upstream release and date b. Link to info on latest maintainer activity on package 4. If an alioth team does not exist, the maintainer creates a collab-maint project 5. The volunteer adds a link to the vcs in their intent to contribute bug report 6. The volunteer adds him or herself as an uploader, makes their other changes (bug fixes, new upstreams, etc.) and pushes to alioth 7. The volunteer either uploads their package (and future updates) directly to the archive (if they're a DD) or seeks a sponsor (if they're not a DD) 8. Continue step 6 and 7 as needed 9. After 6 months of steps 6 and 7, the interested volunteer can send a message to ad...@alioth.debian.org including links and information about their work over those 6 months requesting to become a project admin Note that in step 3, if the existing maintainer disagrees with the alioth admin approval of the volunteer, he should not be allowed to directly override that. He or she would need to make a case to the alioth admins that the new volunteer has been doing problematic things and deserves to be removed; otherwise he or she could continue to block work on the package. Of course all of this is necessary only if the maintainer is not supportive (or reactive) in terms of adding team members him or herself. Importantly this process avoids the negativity of the MIA process (that doesn't apply in these cases anyway since low activity is not zero activity). In the long-term, the MIA process may just go away as instead packages gradually/organically become team-maintained, and the new contributors become established and eventually take over full responsibility as project admins for the packages that they're working on. I know processes within Debian are often seen as bad, but I believe this one is good (or at least better) because it replaces an existing negatively perceived top-down process with a self-directed organic one (i.e. may the best work win). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mo-xocbyp11+we0xyyv2wqy7vkhypa8jh4gu+gyrbd...@mail.gmail.com