project/user account policy (was: Re: Improving freedesktop.org)

[Bastian, Waldo]

Christian Neumair wrote:
>Am Donnerstag, den 31.08.2006, 12:29 -0700 schrieb Bastian, Waldo:
>>
>> My list so far includes:
>>
>>       * Improve website to allow easier tracking of implementation
>>         status of specs.
>>       * Add/expand test suites to specs (which specs in particular?)
>
>A somewhat tighter organized project and user account policy, cf. [1].
I
>really appreciate that the account/web staff is working its butts off,
>but maybe better guidelines are needed when people or projects are
>elegible to get a fdo account, and how we authenticate each other when
>account data has to be changed by administrators?
>
>[1] http://blogs.gnome.org/view/cneumair/2005/10/01/0

Thanks, this is excellent feedback.

I think it's useful here to distinguish between the policy aspects and
the technical means available to support such policies. 

I think there are reasonable procedures in place to handle new accounts.
What may be lacking at times is the desired responsiveness due to the
responsible people being tied up in other work. Are there technical
improvements that could be made to the system/infrastrucuture that would
allow the process to recover better in such situations? 

Likewise with the bugreport that you mention in your blog: It's always a
tricky problem if developer X is being responsible for handling a bug
report and he is busy doing other things. The first solution that comes
to mind is to make sure that developer X gets more time to look at the
bug report but that tends to be very hard to influence. So then the
question becomes, if such a undesirable situation occurs, what can be
done to minimize the damage to the overall process. One thing that I can
think of is being able to see a list of other developers that would be
able to help you: E.g. being able to see the people that have access to
a certain CVS module. Are there other changes that could be made to
improve such a situation?

Cheers,
Waldo