Re: [DPMT] radical changes: automation, carrot and stick
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
Reply to: