Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod
From: Scott Kitterman <debian@kitterman.com>
Newsgroups: linux.debian.maint.python
Subject: Re: [DPMT] radical changes: automation, carrot and stick
Date: Mon, 05 Oct 2015 13:30:01 +0200
Message-ID: <qgc7T-5TG-5@gated-at.bofh.it>
References: <qeViO-2oq-17@gated-at.bofh.it> <qfdpo-37r-21@gated-at.bofh.it> <qfZu1-4r5-5@gated-at.bofh.it>
Old-Return-Path: <debian@kitterman.com>
User-Agent: KMail/4.13.3 (Linux/3.13.0-63-generic; KDE/4.13.3; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Approved: robomod@news.nic.it
Lines: 84
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:7457

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