[AFS3-std] AFS Standardization Proposal
Derrick Brashear
shadow@gmail.com
Mon, 4 Aug 2008 08:57:16 -0400
> *) Defining the Electorate
>
> There have been a number of proposals for changes to the way in which the
> electorate is defined. There seem to be two separate issues - the first is
> whether we place some kind of eligibility hurdle in the way, and the second
> is how we handle 'dead' email addresses, so that the total size of the
> electorate doesn't grow without bound (which is important in order to handle
> the recall case).
>
> Personally, I believe that establishing any kind of competence hurdle is
> going to be extremely difficult to manage. I'd be interested in proposals of
> exactly how such a hurdle could be defined without introducing a significant
> level of subjectivity to the electoral process. Without a competence
> definition that avoids the need to make subjective decisions, my personal
> view is that we can't introduce an eligibility requirement.
An accepted contribution of code or accurate documentation to any
project implementing the AFS3 protocol including one's own is all I
can come up with, and it excludes people who are well-qualified to
speak to matters at hand but happen to be implementing or have
implemented something else or otherwise don't have time to do
implementation work. While I'm not sure this is a horrible thing I can
understand why it would be unpalatable.
> Managing dead email addresses seems best performed through mailman's
> standard mechanisms. Deleting all accounts which don't reply to email, or
> bounce email on a certain data runs the risk of disenfranchising users due
> to technical problems outside their control.
> *) The home of the registrar (and the standards list)
>
> There are two options here - either leaving things as they are at
> grand.central.org, or moving them to systems which are hosted by the OpenAFS
> foundation, in whatever form that takes. It's very difficult to judge this
> at present, without knowing what the foundation can provide. In my opinion
> we should remove the language about where these functions are hosted from
> the document at present, and discuss further when the foundation has come
> into being.
>
This is probably the best course for this now.
Derrick