[gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs

[gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

Hi, everyone.

TL;DR: let's kill obligatory "maintainership" bugs. Maintainer bugs are
enough, and floods of bugs don't help neither maintainers nor
developers.


We seem to have terribly convoluted policies and guides regarding bugs
right now [1,2]. Besides the guides being insanely detailed, the policy
itself is just wrong and creates a lot of meaningless bureaucracy that
only wastes time of both the developers and proxied maintainers.

So, let's say a user wants to take a package along with its
dependencies. Next thing I know, I'm spammed with 15 bugs, one for every
package. Not that they're of any value to me since I won't be tracking
progress for every single one of those packages separately, or that I
need to track the progress via the bug at all.

Things get even worse when developers try to follow policies to
the word, and start linking a lot of random bugs together, creating 50
useless mails for the sake of pretty, meaningless structure.

Not to mention the creeps I get every time I see another person says
'maintainership'. Protip: such a word does not exist. it's
'maintenance'.

Enough bickering. Now, what I propose.


First of all, we kill per-package bugs altogether. We optionally allow
a single 'maintenance request' bug per request, if we need to gather
developer's permission or otherwise have a reason to do some
bureaucracy.

If such a bug is used, the user can list the packages he wants to take
inside, and we can reply with any requests we might have. We *do not*
link any bugs to avoid creating noise.

Otherwise, we can just handle maintenance requests implicitly -- on top
of pull requests or bugs where the user submits patches.


Secondly, we keep maintainer bugs for the purpose of tracking e-mail
address changes and only that. We do not link them, we do not list
packages in them -- just e-mail addresses. If someone wants to check
what the user maintains, he can do a trivial grep on metadata.xml
instead of trying to process all that inconsistent comment noise.

We do not require proxied maintainers to create those bugs up front.
Instead, we open them with a short explanation after merging the first
relevant commit.


Thirdly, we kill those two horrible guides. Instead, I'll add a short
explanation of the two points above to the regular guide at [3].


What do you think?


[1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests
[2]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests
[3]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]

Re: [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

Hi Michał,

thank you for your E-Mail, this was a very interesting read!

Am Montag, 17. Juli 2017, 20:31:13 CEST schrieb Michał Górny:
> Hi, everyone.
> 
> TL;DR: let's kill obligatory "maintainership" bugs. Maintainer bugs are
> enough, and floods of bugs don't help neither maintainers nor
> developers.

The way you describe it, the status quo sounds horrible to me. Much ado about 
nothing, more or less.

> [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_a
> nd_Maintainership_Requests

The whole page sounds sane. Sane in a "Let's-Do-It-Right"-way. But it looks 
like following this guide word-by-word will not only produce a lot of work, 
but also a lot of noise. And only a couple of packages later, that list e-
mails get send to can grow very long indeed.

Reading this page helped me a lot to understand your point.

> [2]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests

This is the first time I ever heard of "Maintainer: ${NAME} (${NICK})" bugs. 
And the whole description does not make much sense to me. Both git and 
metadata.xml should be more than enough, shouldn't they? Why should I want a 
personal (but public) bug to track what I am maintaining?

> [3]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide

I think that this page covers the workflow I am used pretty well. But I'd like 
to see a bit more guiidance for PRs. 
You mention them, and the "Commit Policy for users" section is *highly* 
valuable, but a few lines of guidance about what to squash and how to generate 
which amount of commits in a PR would be great.
(Okay, thanks to the PR reviews, any proxied maintainer would learn by doing 
anyway, but it's people like you having to request changes all over again. ;-) 
)

At the end of the day I am very fond of your update proposal. :-)

Cheers

Sven

-- 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-proxy-maint] Reworking policies: killing "maintainership" bugs

[Sam Jorna]

[-- Attachment #1.1: Type: text/plain, Size: 4378 bytes --]

On 18/07/17 04:31, Michał Górny wrote:
> Hi, everyone.
> 
> TL;DR: let's kill obligatory "maintainership" bugs. Maintainer bugs are
> enough, and floods of bugs don't help neither maintainers nor
> developers.
> 
> 
> We seem to have terribly convoluted policies and guides regarding bugs
> right now [1,2]. Besides the guides being insanely detailed, the policy
> itself is just wrong and creates a lot of meaningless bureaucracy that
> only wastes time of both the developers and proxied maintainers.

The current policies were written at a time when some specific issues
needed to be managed and, as the first attempt at writing such policies,
needed to be reasonably explicit. They also went through the regular RFC
process through the project without objection.

That being said, they were written with both those points in mind - I
welcome improvements.

> So, let's say a user wants to take a package along with its
> dependencies. Next thing I know, I'm spammed with 15 bugs, one for every
> package. Not that they're of any value to me since I won't be tracking
> progress for every single one of those packages separately, or that I
> need to track the progress via the bug at all.
> 
> Things get even worse when developers try to follow policies to
> the word, and start linking a lot of random bugs together, creating 50
> useless mails for the sake of pretty, meaningless structure.
> 
> Not to mention the creeps I get every time I see another person says
> 'maintainership'. Protip: such a word does not exist. it's
> 'maintenance'.

Point out silly things, win silly prizes.

It actually started off as a placeholder as I couldn't think of a more
"real" word with a clear enough distinction between the act of package
maintenance and the state of being a maintainer of a given package.
No-one objected, and here we are. :)

> Enough bickering. Now, what I propose.

awww...

> First of all, we kill per-package bugs altogether. We optionally allow
> a single 'maintenance request' bug per request, if we need to gather
> developer's permission or otherwise have a reason to do some
> bureaucracy.
> 
> If such a bug is used, the user can list the packages he wants to take
> inside, and we can reply with any requests we might have. We *do not*
> link any bugs to avoid creating noise.
> 
> Otherwise, we can just handle maintenance requests implicitly -- on top
> of pull requests or bugs where the user submits patches.

This sounds good to me, however such a simplistic approach doesn't
handle one of the (admittedly corner-case) issues the current process
does - specifically, two users requesting maintenance (the real-word
version) of the same package from two developers, each unaware of the other.

There haven't been many cases of this that I can think of, and it may be
something to be addressed if and when it happens, but I wanted to point
it out.

> Secondly, we keep maintainer bugs for the purpose of tracking e-mail
> address changes and only that. We do not link them, we do not list
> packages in them -- just e-mail addresses. If someone wants to check
> what the user maintains, he can do a trivial grep on metadata.xml
> instead of trying to process all that inconsistent comment noise.

Should existing linked bugs be unlinked (creating one mass-spam) or deal
with them as they come?

> We do not require proxied maintainers to create those bugs up front.
> Instead, we open them with a short explanation after merging the first
> relevant commit

It might be worthwhile doing this before the first commit (at least, if
you haven't worked with the contributor before) - it's a reminder to
check if they already maintain something in the tree.

Somewhat tangential to this, would there be benefit to offering a common
list of resources to new maintainers? Currently reference pages are
largely unknown because there's no clear index of them - most of the
time people only find out about something when someone happens to link
to a reference on it.

> Thirdly, we kill those two horrible guides. Instead, I'll add a short
> explanation of the two points above to the regular guide at [3].

I'd like to see what I'm buying first, but based on the above it sounds
good to me.

-- 
Sam Jorna (wraeth) <wraeth@gentoo.org>
GnuPG Key: D6180C26


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]