Forum OpenACS Q&A: Re: OpenACS Core Team Selection Issues

Collapse
2: Re: OpenACS Core Team Selection Issues (response to 1)
Posted by Malte Sussdorff on 08/18/03 10:20 AM
- The core team should consist of enough members to distribute the workload but not too many to make it inoperable. Somewhere in between 6 and 9.

- A term should be for one year. Maximum two years. This has to do with the fact that in our dynamic environment you should not have to commit yourself to more than a year to a project, if you don't consider to stay in a company for that long :).

- Elections should be held twice per term period. At each election half of the member seats are up for renewal. This allows for a smooth transition.

- Voting should be executed by the People with CVS commit rights that have participated in forum discussions for the last three months. Additional voting rights can be given to active members of the community (a certain number of postings in the last three months). The criteria will be checked by the  OCT and a list of voters published one month before the vote.

- All voters are elligable to be elected. To become a candidate a voter has to have at least one sponsor from the OCT members whose seats are not up for voting (reasoning is that at least one person would like to work on with the new candidate for at least half of his/her term).

- Voting should be conducted in a poll. Each voter has a number of votes equal to the seats in the OCT that become elligable. The front runners win. If there is a tie for the last seat, the OCT (old and newly elected) make a vote between themself (again, they are going to work with the new person, and if the community is indifferent between the two, let the OCT decide).

- We should not make any division based on whatever criteria. We should keep the number of people per organization down to one though.

- Another name: OSC: OpenACS Steering Commitee, or TCS: Technical Steering Commitee

- There is no maximum number of terms a person can serve

- If someone has to leave the OCT, the seat will be empty til the next election. The term of a seat do not change because of this. If the term was from 1st of Jan til 31st of December and next voting is on 30th of June, the new person would have a shorter term (from 1st of July til 31st of December)

Collapse
4: Re: OpenACS Core Team Selection Issues (response to 2)
Posted by Joel Aufrecht on 08/26/03 03:38 PM
Malte, great stuff! Let's keep going: A core team of nine, with one-year terms. The election is Sep 25. We want staggered one-year terms and elections every six months.
  • If we do staggered terms, should four of those nine seats be six-month terms instead of a year?
  • Can candidates choose which seat they're running for?
  • Since the whole OCT is up for "re"-election, do we relax the rule that only OCT members not up for election can sponsor candidates?
  • We have 24 committers and nine seats.
    • it's a month before the election. Who's going to do "a list of voters published one month before the vote?"
    • Should cvs commit power be a qualification for voting in the future? If so, what is the qualification for commit power?
    • How can we open the voting pool to non-coders? If the main criterion is "a certain number of postings in the last three months," what is that number and how will we keep people from abusing that criterion?
    • What other criteria can new people use to qualify?
    • How can we make the electoral body bigger?
  • "OSC: OpenACS Steering Commitee, or TCS: Technical Steering Commitee " Either is fine. Do we see this body as strictly technical, or as the final voice of the community on all topics?
  • "Voting should be conducted in a poll. Each voter has a number of votes equal to the seats in the OCT that become elligable. The front runners win."
    • Where is the poll conducted? Who administers it?
    • Can a voter vote many times for one person? If not, then I think it works like: you have a ballot of e.g. 20 names, and you put a mark next to nine of them. This is approval voting - we simply tally up all the votes for each person and the nine highest totals win.
    • Or do we want to go with a ranking system (instant runoff, Borda, or Condorcet)?
    • Is voting open or secret?
    • As a community using a database-backed web system, we should of course do all this with a voting package. For the immediate election, how about we just use flat text with asterisks or numbers?
Collapse
5: Re: OpenACS Core Team Selection Issues (response to 4)
Posted by Jade Rubick on 08/27/03 06:55 PM
- Staggered terms: I think it's a good idea to have half the inital seats be for 6 month terms.
- I think the people with the most votes should get elected for the longest terms. How about that?
- I think for the initial election we should relax the rule that only OCT members not up for election can sponsor candidates.
- I'm not really sure what other criteria should be used besides CVS commit rights. But we do need to define this. People may then want CVS rights even if they don't commit anything. And then we need a formal set of criteria to determine who gets CVS access.
- I'm not sure that making the electoral body bigger should be the most important goal. I think what's important is that the electoral body reflect those with a large stake in the direction of OpenACS.
- I like Technical Steering Committee. Let's restrict their focus to just technical matters. That seems to be the problem we're trying to address. Why do we need a spokesperson for the community, when it is so diverse? What we need is a solution to which direction we head technically, not a spokesperson.
- I'm fine with approval voting or instant runoff.
- voting should be open, I think. Or at least verifiable.
- flat text is fine for this election.