hottest100 (was Re: Bazaar focus for 2.1 and 2.2)

[Jonathan Lange]

On Thu, Jan 7, 2010 at 2:44 AM, Barry Warsaw <barry at canonical.com> wrote:
> On Jan 6, 2010, at 9:38 AM, Curtis Hovey wrote:
>
>> We have a general problem where knowledgeable contributors cannot update
>> a project because Launchpad made someone else the owner (the owner may
>> not want to be in that role). Examples include setting the product
>> release finder, setting the bug tracker, setting the upstream contact,
>> setting up translations, setting the focus of development (or setting
>> the branch of focus of development), setting the project license [1]
>
> There's really a bigger problem with this, which is that the roles, and the permissions they enable, is not well documented or discoverable.  I was recently reminded of this in two situations.
>
> Mark Sapiro is a co-developer on the Mailman project and does most of the maintenance for the 2.1 series.  He's a member of the ~mailman-coders team, which is the project driver but not maintainer.  That team is also a project driver for the 2.1 series.  Mark is a member of that team, and is the release manager for the series.  The team is the bug supervisor and the security contact.
>
> Over the winter break, Mark wanted to do a release, but was met with many roadblocks because he did not have permission to do things like set certain bug status, make a release, or target issues to a milestone.  He struggled quite a bit on his own before contacting me.  We eventually resolved the issues, but quite a bit of it felt like haphazard voodoo.
>
> On the platform team, I worked on bug 494704 yesterday.  I started by assigning the bug to myself.  I was dismayed that I could not set the status of the bug to Won't Fix or Triaged.  The reason for this is not at all clear or documented.
>
> I think we can and should do a much better job of at least describing which roles enable which permissions.  The current system seems accreted and not at all designed as an integrated whole, and it needs to be rethought.
>
> If there are use cases for why things are the way they are, I don't know where they live.  There are certainly cases where the current situation puts more roadblocks up than are necessary or make sense.
>

I agree.

For almost any of the decisions made on Launchpad, there isn't much in
the way of documentation as to why they were made that way.
Permissions is not an exception here.

Most of the people I talk to admit that the Launchpad permission
system is haphazard, confusing and patchily implemented. What we
really need are concrete next steps, or even better, people willing to
spend time on fixing the problem.

That said, this isn't really the mailing list to talk about Launchpad
permission problems.

jml