[UPHPU] decision making [group project]
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,
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