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