I think that a voting process which involves working both with github, the
issue tracker, and presumably using the network map of branches seems a bit
ornate, puts a barrier to contribution up, and is likely to be confusing.

I think that if a /whatever policy is developed for "how does C4L decide to
resolve conflicts?", that comes first, and then what technological tools
support that should flow naturally from that decision.





On Thu, Jan 24, 2013 at 4:37 PM, Shaun Ellis <[log in to unmask]> wrote:

> I am uneasy about coming up with a policy for banning people (from
>> what?) and voting on it, before it's demonstrated that it's even
>> needed. Can't we just tackle these issues as they come up, in context,
>> rather than in the abstract?
>>
>>
> I share your unease.  But deciding to situations in context without a set
> of guidelines is simply another kind of policy.  I'm actually more uneasy
> about ambiguity over what is acceptable, and no agreed upon way to handle
> it.
>
> I don't think the current policy is ready to "go to vote" as it seems
> there is still some debate over what it should cover and exactly what type
> of behavior it is meant to prevent.
>
> I suggest there is a set time period to submit objections as GitHub issues
> and resolve them before we vote.  Whatever issues can't get resolved end up
> in a branch/fork.  In the end, we vote on each of the forks, or "no policy
> at all".
>
> Does that sound reasonable?
>
>
> --
> Shaun Ellis
> User Interace Developer, Digital Initiatives
> Princeton University Library
>