[UPHPU] decision making [group project]

Mac Newbold mac at macnewbold.com
Mon Jun 6 12:43:04 MDT 2005

Today at 11:07am, John David Anderson said:

>>> This should be the official way to vote. I understand that many might
>>> not have the ability to attend all meetings or any for that matter.
>>> however, there still needs to be an official method for voting and i
>>> think that if anyone attends the meeting their vote should count as 2.
>>> i think that votes via email are the best way for individuals that
>>> cannot attend can still voice their votes. however, i think their count
>>> should be 1.
>> Why make votes at the meeting count as two?  Is someone's opinion less
>> valid because their kid was sick that night?
> <bias>As someone that isn't able to come to meetings, I'd rather not go along 
> with this idea either.</bias>

I am in agreement too, I think. However, if the person not present did not 
get to hear the full debate at the meeting, I think it might be reasonable 
to weight their vote less, since their vote is less informed about the 
discussion and considerations that were examined.

> Voting this way seems to discourage participation from people who can't come 
> to meetings - which is a larger workforce the group can tap into. Can't we 
> "meet" online somehow?

That's a great idea. We could meet online in IRC for example, and discuss 
there and vote there. It can be a little difficult in ways, but has many 
of the advantages of an in-person meeting, like immediate results, most 

> I really like the idea of a maintainer - and sub-maintainers. This project 
> needs leadership or it will die by discussion. I think progress could move 
> quickly if we had talented leads working with teams.

Amen. I'm with David, Wade, and John on this one. We need a maintainer who 
controls the overall direction of the project, and sub-maintainers who are 
overseers for thier part of the project, and can independently make 
decisions within that realm that do not affect the other teams.

> I don't personally like the idea of vote-by-email (because polls are made
> for... polling), but I don't really mind if we end up using it. It would be 
> nice to have a UPHPU-vote list though so the vote emails don't end up mixed in 
> with normal UPHPU or even UPHPU Framework discussions.

Here are the pros and cons I see: if we have a mailing list for votes, 
multiple people will get every copy of every vote. It's a lot of mail, but 
it allows for independent re-counts of everything. If a single person 
is appointed Chief Bean-Counter, and votes go to them only, then everyone 
won't get bogged down in the mail. The Bean Counter could even be two or 
more people who count individually, and each provide their tallies to 
verify the result if it is in question.

Hopefully, if we get a Maintainer or Project Lead or something, and a 
bunch of Overseers in different areas, the need for votes, polls, and the 
dreaded "design-by-committee", will be greatly reduced and will almost 
never need to be used.

Regarding rotation of the Maintainer: The biggest con I see in that is 
that continuity might suffer a lot, and we may end up seeing oversized 
changes in direction every time the maintainer changes. Perhaps the 
"Maintainer" is really a group of people, say Maintainer, Vice-Maintainer 
(who for example may have been the previous Maintainer), and 
Maintainer-Elect (who will be the next Maintainer). So a Maintainer 
(except for the first time) would serve as M-E for one term, then as M for 
another term. The Vice or Past-Maintainer could be something different, 
who knows.

A team of three that works for consensus among them could be a really 
great way to do it. If we don't want three, I'd strongly suggest at least 
having two, so that the current M and the M-E can work together for a 
while, get on the same page, and learn all the ins and outs before the M 
is finished. Maybe even having a Maintainer who is the sole decision 
maker, but having a M-E and a Past Maintainer as ex-oficio non-voting 
members of the three person committee would be best. Having the past one 
would be a great resource, and enlighten us about where we've been and 
where we are, and having the future one there would do more to ensure the 
continued success of the project.

A term could be 6 months, a year, or "as long as the maintainer wants to 
keep doing it, not to exceed X year(s)". I think that continued dedication 
and availability of the maintainer is key, and if at any point they want 
to resign, there should be someone ready to step up, even if the previous 
M may not be readily available any more.

Setting something up like that would be really good I think. The FreeBSD 
team has a Core team that makes all the big decisions, and it works really 
well for them. Our Core would be the Maintainer (/M. Committee) and all of 
the Overseers who are in charge of the different components.

IMHO, the only requirements for these positions should be interest,
dedication, and availability. Skill would hopefully be apparent in a 
maintainer, but in an overseer, I think it's just a plus rather than a 
requirement. If someone wants to work on a particular piece of the puzzle, 
even if they've never done it before, I think they should be eligible to 
serve as Overseer for that portion. If other interested people are more 
qualified, hopefully they'd be chosen.

One more thought: The Maintainer could potentially serve as Overseer for 
one area, but it should be avoided when possible, and they don't get 
double votes on the Core.

Anyway, a bunch of thoughts strung together with ASCII. Hopefully it made 
some sense to someone, and there's something useful in there.


Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/

More information about the UPHPU mailing list