-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAly/13MACgkQ4n8s+EWM
L6TXLRAAtcNQ0O9TF23ZfntvTH/vPKnCwkGfH7+eForJKX0AOMDWGgVi2+77a5f0
P+3SclqnYuDoCf74f7dF/SmvyV1VLn9Z3Sefk2yiRud3frKzxDW9rX6kyTkSDvU3
WwfWT521pGrNvQfGGMUsmcRhFb633VJeJVaWdfHgq4N5NPO2oy6r+6xnJDGaWNWv
vT+xxt1Y+41wBa7kG4Ic5LxFNODQ4L+Ks2euoAxRcAW5Dp+kAz6gPByrLVhOxITi
7W3vWsXC3F6nrSveqLfxDFU7JnynfLNoUc0bzC3RRCaOnEyxOZUf9ezN0+tusABF
b09yPyvEGBamQ+6tkIy5lYszMEcuHs4ovWWuxogMtWFTLdEc+gG6oKfVjYTX/93J
zzxTEEjhdmjggeIB6QmHPViMxnAo4P9odalSqDbK9U7bn94sC/H2ZPp/jBqc43YG
0TNV6+2L7ovUNfFCyIQ2s7Yxz9J62dH3n11ZpbSeMBBZBw77tbjDMR1uneDvneiH
tZkeazj9iZllUA9Kdo9BKqI1uFxKkuZJXYM8A6C/4alj75BVA9qdnjkwsIP8QV/E
TWUvo3ZKiODfqoRB0gKoLRlMahqKqO2lShMDmqq3z/fdJjbfsphoc76AOVctVdz5
oARPQKXD7GEZUULQWAnDS9S3pW0lpF9MbBQ8vWhqFQb0gL4es5s=
=PIes
-----END PGP SIGNATURE-----
Hello Sebastien,
On 4/23/19 4:47 AM, Sebastien Bacher wrote:
> Hey Simon,
>
> Le 21/04/2019 à 00:12, Simon Quigley a écrit :
>> Today I spent a few hours sifting through the sponsorship queue. I
>> sponsored everything I could review and was comfortable sponsoring, and
>> asked for changes on many bug reports. The queue started out at about 70
>> (I didn't catch the exact number) and is now down to 13.
>
> Good work, it's nice to see some sponsoring activity :-)
Thanks (to Robie and Gunnar as well)!
>> One of the most common changes I requested was that people edit bug
>> descriptions to follow the SRU template for bugs which have sponsorship
>> requests open for stable releases. Perhaps a message recommending that
>> could be added to Brian's automatic reply bot.
>
> I'm not sure I agree with that being enough of a reason to get them out
> of the sponsoring queue though. Did you unsubscribe sponsors? Or marked
> them incomplete? It would be nice to keep those on the list in some way
> because they can still be useful.
>
> Depending of the fix I sometime do edit the description myself&do the
> upload rather than bouncing back to the contributor.
>
> While it's nicer when the bug is ready/needs to work, I don't think
> enforcing roundtrips over 'paperwork' always benefits the project. When
> a fix makes sense and addresses a real issue which is easy to verify it
> can be less effort for everyone to have the sponsor go the extra mile.
>
> (in some cases it's not obvious how the bugs can be triggered/tested,
> then it makes sense to ask for the details and set as incomplete though).
While I agree with Robie that we have limited contributors working on
the queue (I have noticed more activity lately from others, thank you!),
my rationale was to review it purely with an Ubuntu Sponsors Team hat on
while I was getting the queue to a manageable point; a package is either
ready to sponsor (sometimes with fix-ups) or it isn't. Sometimes, I can
understand what a patch is doing by reviewing it, but I would like to
understand the wider ramifications (if any) from the person that
reported it. While I recognize this isn't always the case, getting their
feedback from what can otherwise be a terse bug report has, in my
experience at least, led to a higher quality paperwork end result.
Perhaps this is because most of the items I have dealt with recently
either have an Ubuntu Developer, a Canonical employee, a Debian
Developer, and/or upstream working on them.
I would like to address the wider point here, though. Right now we have
no way to leave a comment directly on the sponsorship queue, much like
we do with MoM, which would solve this. We have sorting, but the CSS
(while not entirely important) looks outdated. While I could spend a day
or two polishing that page specifically, and make it look presentable
with all the fields we would need, we have several other pages that are
in a similar state. Here are a few examples:
https://people.canonical.com/~ubuntu-archive/pending-sru.html
https://people.canonical.com/~ubuntu-archive/phased-updates.html
http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
These pages are quite scattered; while outputs can come from different
machines (I have no idea what this looks like internally at Canonical,
this is just a guess) and different sources (Britney, sru-report, etc.),
it would be nice to bookmark *one* page that has each of these as clean,
modern-looking, and consistent pages as sub-pages. From there, we could
generate reports, perhaps similar to the Debian Maintainer Dashboard.
I understand this might seem like a significant undertaking, and I am
willing to do the work in order to make this happen, but I would like to
have the conversation about whether others would find this useful.
Please let me know if you are an Ubuntu Developer who would like this
(or if you object to it, more importantly), and I can create an initial
specification and mockup to send back to this thread.
Thanks!
--
Simon Quigley
tsimonq2@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
