 |
 |
Shaun Ellis <[log in to unmask]> > 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? No - for a whole shedload of reasons, but I'll just mention one: GitHub demands everyone's full legal name, which some minority members just won't be comfortable with giving. For example, if they are opposing some aspect of the policy or may risk their livelihood (does the US military still do Don't-Ask-Don't-Tell?). I'd also like to suggest Crowd-Wise http://www.neweconomics.org/projects/crowd-wise as a possible way to vote on such things without a majority dismissing a minority almost every single time. A quick summary: gather all ideas (including option 0 (do nothing) if possible), carry out a de Borda (preference) voting round 1, merge/amend/consolidate ideas to try to get consensus or at least an overwhelming majority, then voting round 2 if needed. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/