evening the entry bar: git account management

[Aaron J. Seigo]

On February 17, 2010, Daniel Stone wrote:
> On Tue, Feb 16, 2010 at 12:24:50PM -0800, Aaron J. Seigo wrote:
> > but it is linked to from the next sentence in the paragraph on the main
> > page. the linked sentence itself is: "See AccountRequests for
> > information on how to obtain CVS access to a project." CVS?
> 
> At the risk of being overly blunt -- it's a fucking wiki.  There's an
> edit button; I'm willing to bet that it's fixable in far, far less time
> than it took to write this email.

The first thing I tried was clicking on the edit button. I got a "this page is 
locked for editting". Yes, I was logged in.

I see today that that has been changed and it is now editable when I click on 
that button. That's great!

Even then, I don't think I'd just dive on in and edit without first getting 
some basic directional consensus here. We currently lack the togetherness 
around freedesktop.org to make changes that are coordinated without 
communicating first. Over time that will change.

I am tired, however, of what has become your trademark sarcasm and grumpiness, 
Daniel. Your "it's a fucking wiki" comment is exceptionally lame since this 
was not the case yesterday as it was locked down then. Now, I don't know (nor 
care) what crawled up your ass, but I really hope that the rest of us can 
build a community around freedesktop.org that's more welcoming and friendly. 
I'd prefer it if you could join us in making that happen since we need every 
intelligent an well-meaning person we can get (and I do think you have both of 
those qualities).

> > the text on AccountRequests is the opposite of friendly: "To obtain an
> > account for a project hosted by freedesktop.org, you must follow these
> > rules. Failure to do so will probably result in your request getting
> > dropped on the floor. Don't take it personally if it does, the rules are
> > there to make sure it doesn't happen, so if they aren't followed ..."
> > 
> > that doesn't particularly make me want to get involved.
> 
> Fair.  Do you have any particular suggestions?

Absolutely; basically it's just getting rid of the sarcasm and grumpiness, 
like:

"To obtain an account for a project hosted by freedesktop.org, follow the 
guidelines below. To ensure speedy processing of your request, please double 
check that all of the necessary information is provided in complete form. 
Account requests that do not supply all of the necessary information listed 
below will not be able to be fulfilled and will instead be sent back to the 
submitter with a request for more information. "

> > the page doesn't describe who would qualify for an account or who i
> > should consult to see i i might qualify (i've got to figure that part
> > out for myself; ime, contributors rarely manage that on their own)
> 
> Which project are you contributing to? Are you writing a 3D driver for
> Mesa, are you submitting a patch for a spec, ... ?

Absolutely; each hosted project should have a note describing who to contact 
for such information. Or at least, there should be space provided for projects 
that wish to publish such information. (I don't expect all projects will want 
to be open and inviting in this manner.) So for the xgd specs repo, it would 
be great to have some text there describing who qualifies (anyone maintaining 
a specification in the repository) and where they can be discussed 
(xdg at lists.freedesktop.org). This probably belongs on a new page otherwise 
there will be too big a listing and it will drown out the rest of the content 
on the page.

> > the instructions are poor:
> > 
> > "Create a bug asking for an account. Select the Product that corresponds
> > to the Project for which you are requesting access. If there's no
> > product in bugzilla for the project in question, file it against the
> > freedesktop.org product, in the New Accounts component."
> > 
> > there is no hint as to what to use as the title or the component; i
> > assume that noticing requests for accounts happens by diligent people
> > reading through all new bug reports? sounds like a system that lends
> > itself to accidental failure?
> 
> How do you suggest we do it, given that the projects themselves may have
> wildly different methods for deciding who should and should not have
> edit access to their project? What if the Mesa guys want something
> different to the X.Org guys who provably want something different to you
> who may or may not want something different to others on this list?

There are a couple of workflows I can think of that would fit these 
requirements. Here's on possible one:

* all Account Request bug reports would be tagged in a searchable way, and a 
shared stored search added to the bugzilla so that all requests can be easily 
seen/tracked

* an Account Request bug report would still be filed against the target 
project (for the reasons you note above)

* to signify that a request is accepted, a member of the project must change 
the status of the bug from UNCONFIRMED to ASSIGNED; at this point the people 
who manage the git (or whatever kind) accounts have the go-ahead to add the 
account

* a maximum time frame is given to Account Request bugs after this point for 
fulfillment; say, one week? if that fails, then we revisit the account 
staffing and add more/different people if needed to decrease the latency

* if a requester does not get a response in a reasonable time frame (as 
defined by the policy we create and publish on freedesktop.org), they are 
directed to this list to raise a red flag so it can be sorted

this way we can easily track:

* all requests
* all requests that have not been confirmed by a project member within X days
* all requests that have been accepted (ASSIGNED) but not fulfilled by sys 
admin within X days
* requesters always have a described set of expectations as well as recourse 
to follow if the process fails them

transparency and accountability; the only changes needed would be a couple of 
stored searches, a shared tag for all account requests in bugzilla and some 
monitoring of the situation.

> > i'd like to do more than observe/complain, but i can't edit any of these
> > pages because the wiki is locked down even when logged in. so, sorry
> > about not doing something about the above.
> 
> > compare and contrast the AccountsRequest page with what we use in KDE:
> This is irrelevant: KDE is a single monolithic project.  X.Org people
> are not qualified to decide who should get a HAL account, or whatever.
> So yes, it would be nice if policies were unified, but the reality is
> that they're not because we are one host for myriad projects.

freedesktop.org is offering monolithic hosting. which means there's a shared 
bottleneck on getting access to the git repository. the fact that there is ONE 
AccountsRequest page proves this. there is, however, no standard way of 
tracking which is a requirement for the transparency and accountability any 
healthy community requires.

you are right that there are a myriad of approval points, but that's covered 
in the workflow described earlier.

> > > > how long does it take to get an account set up?
> > > 
> > > Not long.
> > 
> > how long is long?
> 
> 97 minutes.

except for that guy who waiting 13 months and change. this is not the first 
time i've heard of this. but your answer also misses the point: what we need 
is a description of what is acceptable.

i don't think every account request needs to be fulfilled within 1.5 hours. 
but as a requester, should i be worried if it takes 3 days? 7 days? a month? 6 
hours? we need to set expectations for both the requester to feel confident 
and for us to measure and regulate our own ability to meet reasonable service 
levels.

> > what is the policy on what is too long?
> 
> Common sense.

that doesn't work, and not because we don't have common sense but because 
without some shared idea of what is too long requesters won't know when to 
raise a red flag and we will have no way of saying, "hm, we're not doing well 
enough according to our own expectations and need to improve things."

> > > > who is responsible for making this happen? (and hopefully it's more
> > > > than one person)
> > > 
> > > A few people.  Not me.
> > 
> > where are these "few people" defined?
> 
> ssh annarchy.freedesktop.org 'getent passwd | cut -f1 -d: | egrep "R$"'

and how does someone who doesn't have ssh access to annarchy.freedesktop.org 
get this? and why is it hidden behind passwd files? is everyone who has an 
account there responsible, willing and able to set up git files?

if we want freedesktop.org to actually -function- for all involved* then these 
things need to be documented much more openly.


* e.g. not just for a few who are happy with the current state of affairs 
because it serves them well due to having direct control without 
accountability

> > what is the community accountability?
> 
> In what sense?

in the sense that when we fail, as in the case of waiting 13+ months for an 
account, we can measure that and figure out where we need improvement.

> > how do they know if a request should get approved for a given product?
> 
> Well, as you can see from the AccountRequests page, people in a position
> of authority for the particular project approve or deny the request, and
> then forward it on to the admins who implement their wishes.

and yet there is no description of what time frames this encompasses, nothing 
that says how to tag a bug report as an account request, nothing that says how 
to mark a bug as approved for the request gets fullfilled.

what i do see is a set of chain links but no actual chaining: someone fills in 
a bug report and hopes they make it clear it's an account request; hopefully 
someone in that project notices and takes action on the bug report; hopefully 
someone then tells the admins (who are they again? right, it's not well 
documented!); hopefully the admins fulfill the request.

at each stop in that process there is a real opportunity for it to drop on the 
floor and get passed by with no way to measure and keep track of it. this is 
why some accounts take 13+ months.

> > in general, there is a lack of transparency that makes it more difficult
> > than necessary to get a grasp on how to get involved (or even if one
> > would want to).
> 
> What would you like to get involved with?

the xdg specs repository. and i'd like others to be able to do so easily as 
well.

> > i would like to help fd.o document the processes better, improve the
> > clarity o the website (starting with examining who can edit it) and
> > re-assess how git accounts are handed.
> > 
> > thoughts?
> 
> You can now edit the wiki to your heart's content, but please try to
> restrict your edits to actual reflections on how things today work,
> rather than your vision of how you believe fd.o should work. 

Yes, I will be editting the wiki to better reflect the current status quo. 
That is important and I don't expect others to do it for me :)

I will, however, also continue to push for reform because what we have now 
does not work. 

> I'm happy
> to clear anything up should you have any questions.

Thanks :)

> Beyond that, what do you actually want to reassess? Bearing in mind that
> we have a large number of disparate projects with wildly different
> criteria for who should and should not have an account (not to mention
> that those projects are the only ones qualified to work out whether
> people should or shouldn't have accounts), what do you suggest for
> creating new accounts?

I've covered these questions in detail above :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks