On Friday, October 02, 2015 01:18:00 AM Piotr Ożarowski wrote: > I think that the main problem of our team is that we have over 300 > members and only few people contribute to packages they didn't inject to > the repo (some people do not care even about those). I think this is in part because we have a culture that discourages this. I do it, but only, as a rule, for packages that have DPMT set as maintainer. > Here are some ideas on how to change that: > * team only in Uploaders field, the main contact (AKA Maintainer) has to > be real person (reason: nobody reads -team mailing list) + automatic > team subscription via script that sets up git repository Personally, I like the current approach where someone can either commit to either strong team maintainership (DPMT in maintainer) or weak team involvement (DPMT as uploader). If you'll check, I have done both and it reflects my level of interest in the package. If I'm maintainer, absent urgent things like RC bug fixes, I expect to know about things before they go in the archive (delayed or not). I do read the list as the bugs come in. I don't necessarily try and deal with all of them, but I do tackle them as i have time. I wish more people would do this, but changing the DPMT to uploader isn't going to help that. Even if more people get bug mail, we can't make them read it. > * when someone who is not listed in debian/control (i.e. > Maintainer/Uploaders) wants to upload team package - just commit > and upload to DELAYED/2 (in case of RC bug) or to DELAYED/7, no need > to notify anyone, because... I think for RC issues, just upload. For non-RC issues, I don't think just uploading, even to delayed is OK. > * emails with all commits (diffs) made by someone not listed in Maintainer > are automatically sent to Maintainer I like this idea, although I think it's OK to limit it to mailing diffs by someone neither in uploaders nor maintainer. In cases where I have active co- maintainers in uploaders, there's no need to mail their commits to me as I trust them. BTW, don't forget that once we switch to git, the repos will be full source, not just /debian so these diffs could get large. > * adding a package to the team (and getting all benefits, like > sponsoring, bug fixes, etc.) requires pushing at least one commit to > package without member's name in debian/control a month > (doesn't matter if it's a typo fix, RC bug fix or a tag which can > be made only by those who upload/sponsor packages from now on) I think any sponsor can ask people do this now. We don't need a rule. > * automatic emails with a warning if there's more than 31 days since the > last contribution described above > * removal¹ of packages (not person) from the team if there's no > contribution in 3 months in a row (and given person is not MIA, as in > active in other packages, for MIA ones: decide if someone wants to > take over or orphan the package, no more team packages that nobody > takes care of and no objections if someone takes over your package) Personally, I would find this kind of rule demotivating. I think it will actually discourage participation which isn't what we want. > I can implement all scripts that automate above tasks but someone > will have to replace me in the admin seat. > > [¹] as in upload to unstable without DPMT in Uploaders, repo stays in > case one decides come back I liike some of your suggestions. I definitely agree with the goal of trying to get more people working on a team wide basis. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.