[UPHPU] decision making [group project]

David Boucha boucha at gmail.com
Mon Jun 6 10:55:27 MDT 2005

On 6/3/05, Mac Newbold <mac at macnewbold.com> wrote:
> After recent discussions on the list, I'm concerned about how decisions
> will be made regarding the group project, meaning the process, not the
> result. I'm assuming that we're planning to run this project mostly like a
> democracy, in the same way that UPHPU is run, and that everyone's input is
> welcome, then majority rule will for the most part decide things.
> We've got some tough problems though, because while the meetings would be
> a great place to decide in person, not everyone can attend every meeting.
> We typically will not know before the meeting what the decisions or
> options will be, and the discussion (in person and/or on the list) will
> often influence opinions greatly.
> I'm going to throw out a few options, and let's talk about them.
> A. Decide in-person by a vote at an official group meeting.
> IMHO, the simplest way to do it, and the most effective, because of the
> possibility of immediate feedback. However, those in attendance are the
> only ones that carry weight in those decisions. Also kind of nice that the
> discussion and the vote take place in the same way. Variations on this
> might require a minimum number of people to be there, or that the decision
> isn't officially final until it's ratified (by extending the vote to those
> not present by some other means).
> B. Decide via email on the [soon-to-be-created] project mailing list.
> Everyone will get their shot at input, if they check mail regularly. May
> create a large volume of mail in the form of ballots. Somewhat slow,
> because we've got to give everyone time to respond.  Probably at least
> 24-48hrs delay before getting a result. When you have questions that can't
> be decided in parallel, where one depends on the other, that can take a
> long time to get to the final result. Also kind of nice that the
> discussion and the vote take place in the same way.
> C. Decide via a poll on the UPHPU web site.
> We'd have to take care that anonymous users can't vote, and then the
> system will make sure there's only one vote per person. Many of the same
> problems as the mailing list option, except for the volume of mail issue.
> But replace that with a I-can't-change-my-vote issue.
> I'm sure there are other options out there, but these are the ones I
> thought of first.
> What does everyone think?
> We really will need an effective way to make final decisions in a timely
> fashion, or we'll just wallow in indecision with endless debate for months
> at a time. We've already seen several issues that could easily turn into
> that, if we let them.
> Thanks,
> Mac

The development-by-committee method will doom this project to failure.
A committee, whether meeting in person or by email will fail at a
project like this.

How do successful open-source projects succeed? From what I've seen it
generally goes something like this:

1. Developer starts a useful project to scratch an itch
2. Developer licenses project under a free license and places the code
in a publicly available place, ie: ftp site, cvs, subversion
3. Other developers find the project useful and start using it.
4. Users and developers send in feedback, bug reports, request for
features, ideas, and code that improves/adds features to the project.
5. Generally a meritocracy develops. This means, most developers can't
commit changes directly to the code in the versioning software. But as
the maintainer begins to trust and depend on specific developers, they
gain commit rights also.

This project needs someone who will make the final decisions as to
what code makes it into the project and guides the overall direction.

I know it sounds nice to say "Everyone gets a say as to what happens
in our project" etc, but this will not work. We'll sit here reading
hundreds of emails about minutia that doesn't really matter. Not a lot
of code will be written.

The ideas that have been expressed here are very interesting. I would
love to have a basic framework that will handle all the repetitive
back end stuff and am willing to help with it.

Let's vote on a maintainer, (maybe pick a new one once a year). Let's
get a subversion repository working and start letting people code. We
could have people in charge of sub projects, ie authentication, plugin
system, css, layout, i18n. Let people start working on those areas
they are interested and excel in.

There are a lot of top notch people on this list, and I think we could
come up with a great project. Let's not let it get bogged down in a

Sorry for the long email

David Boucha

More information about the UPHPU mailing list