evening the entry bar: git account management

[Daniel Stone]

On Wed, Feb 17, 2010 at 09:59:30AM -0800, Aaron J. Seigo wrote:
> 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 didn't realise -- my apologies.

> 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 hope so.

> 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).

At the risk of proving your point, I'll say that I'm polite and friendly
by default, until people give me a reason to be otherwise.  Suffice to
say that I'd count the last two or so years as reason to be otherwise.

> > > 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:

FWIW, the sarcasm and grumpiness was present from revision #1, which had
nothing to do with me whatsoever:
http://www.freedesktop.org/wiki/AccountRequests?action=recall&rev=1

> "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. "

Sounds good -- feel free to throw that in there.

> > > 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.

Right.  It would be great if our projects had more coherence, but I
think the best we can do is for every project to have a page describing
what qualifies -- which will often not be objective; requests for X are
dealt with on a case-by-case basis, and there's no particular threshold
-- and then link to that from AccountRequests.  So if you wanted to
create an XDG page describing the process and link to that from
AccountRequests or a subpage or similar, please feel free.

> > > 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

I guess we could add a keyword, but I don't know how useful that would
end up being, if the account requests are all blocking on the relevant
project maintainers anyway? We can't really force maintainers to do
things with their projects against their will ...

> * 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

Right now this is handled by saying 'yep, that's fine with me' and
reassigning to freedesktop.org/New Accounts, which I think works fairly
well.  The only place this falls apart is projects we host who do not
make use of our BZ.

> * 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

I think one week's a bit harsh (what if people are sick, etc), but two
weeks seems fair.  If there are any particular bugs which are lagging
behind come March (give Tollef some time to work through the immense
backlog), then feel free to ping them.

> * 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 sounds a bit like over-optimising for failure here, but I guess the
pessimism is probably borne out by history.

> this way we can easily track:
> 
> * all requests
> * all requests that have not been confirmed by a project member within X days

Again, I don't think these are wildly useful given that we'd probably be
depending on the project leader to do something; it's not our job to
police how projects are run.

> * all requests that have been accepted (ASSIGNED) but not fulfilled by sys 
> admin within X days

This is doable now by just looking at freedesktop.org/New Accounts in
BZ.

> * requesters always have a described set of expectations as well as recourse 
> to follow if the process fails them

Except for step A: what if the project maintainer goes AWOL for a month?

> > > 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.

I don't know that it's really _a_ community, though.  Surely the XDG
community has orders of magnitude more in common with the GTK and Qt
communities than it does with, say, Mesa or GStreamer?

> > > > > 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.

OK, so say two weeks then.  I think we can confidently say that what
happened in the past was so anomalous -- the entire admin body having
either implicitly (most others) or explicitly (me) disclaimed any
responsibility for admin work whatsoever -- that it doesn't really have
much bearing on now.  But still, feel free to put down two weeks for the
fd.o admin processing workload and come yell at us if we fail.

> > > > > 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

I'm kind of concerned about how far 'accountability' goes -- I have
root, and so does anholt.  Neither of us have done particularly much
over the past year, so does that mean we should expect hate mail for
being shit? This obviously isn't to suggest whatsoever that the admins
should be wholly responsible at every single step and not do a thing
which reflects poorly on us.

FWIW, the current admin is Tollef Fog Heen <tfheen at err.no>, and I guess
I'm the backup admin in case of severe disaster.

It's not 'hidden', we've just never felt any particular need to document
it before, nor has anyone asked up until now.  It used to be widely
publicised that I was the admin for fd.o, which in effect meant that
people didn't even bother with the published procedures, so instead of
tracking requests publicly, my inbox was the request tracker for fd.o.
Ironically, this basically led to me giving up, because it did not scale
in the least.  So I'd definitely prefer this not happen again, and that
we make sure people use the infrastructure as much as humanly possible.

Also, yes, everyone who has root is entirely able to set up git
repositories.  They may not be willing to for various reasons (mostly
time and fear of getting dragged in), which is why we hide behind the
infrastructure we've set up to handle this -- Bugzilla, et al.

> > > 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.

I don't have a clever answer here, beyond that if someone's waiting 13+
months for an account, admin is obviously broken and needs to be fixed
somehow.

> > > 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.

Hm, that seems reasonably clear to me, but again, more than open to
suggestions.

(That goes for the entire wiki.  I know it sucks: I started cleaning up
the X.Org wiki with the best intentions of doing fd.o afterwards, but
after a while the sheer scale of the task became clear, and I decided
what time I was throwing at fd.o stuff was best spent on X.Org rather
than wikis.  Help welcome.)

> 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.

Sure.  As we have no influence over the project, the position we take
(which could fairly be called a cop-out) is that getting dropped on the
floor in the first stage is not entirely our problem.  In the latter
stages, you can quite clearly see the date at which it was switched to
freedesktop.org/New Accounts, what the date is now, and do the maths.
None of this prevents it from being dropped on the floor, because
nothing prevents Tollef, myself, ajax, keithp, anholt, etc, etc, from
all contracting ultra-resistant tuberculosis and dying a horrible and
painful death.

Again, the reason some accounts took 13+ months is because there was
no-one doing any kind of co-ordinated admin work then.  Some accounts
took 13+ months, because who's going to notice that in a sea of 200-odd
bugs filed against the freedesktop.org product? Now we have real admins,
it should become apparent pretty damn quickly if we're not doing our
job, because it stands out as the exception rather than the rule.

> > > 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.

Well, I've nothing to do with the XDG group other than having joined
this list to be the admin scapegoat when fd.o was getting quite
furiously shitcanned, as I'm sure you remember.  If Tollef or myself
look at an account request for XDG, we have no idea what to do with it.
How the XDG group -- Vincent, you, whoever -- manage your project is
entirely up to you.

> > > 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 :)

Nice -- thanks a bunch.

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

The primary complaint has been that the admins have mostly failed to
exist, which is entirely accurate, but we do at least now have a paid
sysadmin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20100217/cca2acaa/attachment-0001.pgp