On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote: > 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.
I think that you describe to reasonably accurate directions the team can go. Personally, I prefer the "natural home for most Python packages in the archive" vision. I think we should have a minimum of rules, but people should follow the ones we do have. Scott K
