This thread has had me thinking a bit. Hi Scott (2015.10.02_20:34:16_+0200) > 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.
I like it too, but I don't actually use it very accurately. Whether I'm maintainer or uploader for a package is more an accident of history than anything else. I should probably fix that. That said I haven't found it makes much difference to people's contributions to my packages. I've woken up to find that something was added to SVN and uploaded, immediately. > Personally, I would find this kind of rule demotivating. I think it will > actually discourage participation which isn't what we want. There's a fundamental question to ask here. Do we want to welcome Python packages into the team, or do we want to put up barriers and require a level of commitment before packages can be brought into the team? What are the possible outcomes of either choice? I'd imagine that if we're open, we become the natural home for most Python packages in the archive. Transitions become easier, and standardisation of the vast majority of Python packages in the archive is within our power. We'll collect cruft. But so does the rest of the archive. I don't think being open will necessarily increase the amount of crufty Python in the archive. On the other hand, if we raise barriers, we reduce the size and influence of the team. The few packages we maintain, we can probably maintain to a higher standard. Maybe there'd be less bickering, because we'd be working together more (not that I think we have much). Newcomers would be rarer (there's a commitment) but more valuable to the team. Or would we start to attract people faster because of our level of activity? Of the newcomers we turn away, I don't think most will abandon their pet packages. They'll just not do it in our team. New Python teams will form, and many more Python packages will be individually maintained. I know most of us have QA interests wider than the team, and this isn't desirable for us. How would we feel if a cabal-free-python team formed? Would any of us join it? And as to cruft. What happens when a widely-used package that is maintained by a 3-month inactive maintainer gets evicted? Do we orphan it? Alternatively, is the team prepared to take on all these packages? If we want to seriously think about these issues, should we start lighter-weight? * Audit the team for crufty packages that should be RMed. * or need love. * Audit the team for inactive members. * ... and their packages. Doing something about these is within our power right now. Can we find "carrot" ways to encourage team members to work on packages besides their own? Many of the problems arising from inactive team members are problems that affect the wider Debian, equally. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
