On Thu, 12 Apr 2007 15:46:02 +0200, Greger V. Teigre wrote

Dear all, The way decisions has been made for SER and iptel.org is not explicitly described anywhere. In fact, there has not really been an official policy for how to make decisions. The consequence has been that some decisions have come out of consensus on the mailing lists (normally the developer mailing lists), some have come out of developers/individuals doing something they believe in and nobody has objected, and finally, in some areas, a small group of people have had private discussions before doing something.

The truth is that for a casual observer (on a user mailing list) it has been hard to understand how (and why) iptel.org projects move forward. It is also easy to get to the wrong conclusions and iptel.org has suffered from this lack of transparency.

Over the last year we have worked to make such processes more transparent and predictable. We have focused on development and development decisions and have tried to encourage discussions on the mailing lists, as well as to create wishlists and (starting) roadmaps (see iptel.org website for these). However, we have not addressed management issues like how to solve conflicts where no consensus can be reached and so on. Jan (Janak) raised this issue during the Prague Developer Workshop where 18 people participated. I will below try to summarize what we had agreement on and what was decided. In order to make sure this is accurate, several participants with different views have reviewed this post before sending it on the mailing lists. (enclosed in objective tags)

<objective> Principles agreed to (but up for discussion in the spirit of IETF):

1. We want discussions on the mailing lists and consensus when

making decisions 2. We don't want a lot of bureaucracy that sounds nice, but that we don't need. This includes how to resolve all sorts of issues 3. In general, we trust people (that is individuals, not companies) who are most knowledgeable and most involved to make good decisions on our behalf. Hence, contributors should have more to say in the areas they contribute (ex. module developers) 4. We want to avoid "do-nothing" decisions, for example if everybody agrees, but one person says no, or people are split in two camps

Decisions made (but up for discussion on the mailing lists in the spirit of IETF): * Discussions should be held on the developer mailing lists and no formal voting process should be used * If discussions just continue and no consensus can be reached, we want a small technical board (TB) to have the authority to make the decision on behalf of the community * This board should be elected by the community in an open election process * The technical board (TB) should also have the authority to decide how to resolve issues if there are no obvious precedence from earlier cases * The TB should be elected by the community for a pre-defined period * The TB should focus on issues related to day-to-day development of the projects, but should not manage on a day-to-day basis, just convene if there are issues that could not be resolved by consensus </objective>

I try here to identify open issues not discussed/decided:

• Should there be one TB for all iptel.org projects or one TB for each?
• What should be the criteria for selecting people on the TB (if any)

? * Who have voting rights when we vote on candidates for the TB? * What should be the term for a TB member? * Should this TB handle any issues beyond development? (ex. website content, iptel.org in the wider SIP context, relationship with other projects, packaging, longer-term positioning of projects, longer-term development goals, and so on) * If not, do we need another group that could handle such things?

Best regards, Greger _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

I'll toss in my 2p worth:

1) Should there be one TB for all iptel.org projects?

Yes. It seems needlessly complex to have multiple technical boards running about, each being the deciding factors on any number of projects. If IPTel is the umbrella under which is all goes, it only makes sense to have ONE managing body. That way, it's easier for one group to know the ins and outs about all the subprojects, and there's less that has to be organised for the purpose of maintaining communication between the technical boards.

2) What should be the criteria for selecting people on the TB (if any)?

Ideally, it should be a collection from various teams and perhaps one or two industry-savvy members who can give input in that area. A representative from each area should help give representation to all parties and keep anyone from feeling like their voice won't be heard. It should also be an odd number of people or there needs to be a formal way to break tie votes in the case of a deadlock.

3) Who have voting rights when we vote on candidates for the TB?

I believe a formal nomination/voting process would be best, with voting to be allowable by both development and non-development interested parties. Again, there needs to be a formal process for breaking a tie vote, with perhaps the tie going to those actually in the development process, in order of seniority.

4) What should be the term for a TB member?

Two years at a time with the possibility of consecutive terms (and, possibly, term limits).

5) Should this TB handle any issues beyond development? (ex. website content, iptel.org in the wider SIP context, relationship with other projects, packaging, longer-term positioning of projects, longer-term development goals, and so on)?

Yes. Again, the board should be an umbrella under which technical direction is ultimately decided in the case of inability to solve the direction via normal due course. The web site content, longer-term positioning of projects, long-term goals, visions of the future -- all of that is exceptionally important when dealing with the IPTel projects. While it may have started off as a simple SIP stack program and a few supporting bits here and there, the various projects under IPTel have had massive impact on a rapidly-emerging communications technology that we can scarcely begin to envision. As time goes on, all aspects of these projects, from the way they're positioned for future growth, to the way they're accessible to those who use them will be of paramount importance. Even something as simple as a website look and feel can make a drastic difference in the appearance and accessibility of the projects as a whole, and it should have some formal oversight -- even if no one ever steps in to exert authority.

That's my opinion. Again, take it for what it's worth. My shiny, 2 pence.

N.

Greetings,

Greger V. Teigre wrote:

I try here to identify open issues not discussed/decided:

• Should there be one TB for all iptel.org projects or one TB for each?

I would incline to a No. I'm not yet convinced that all (other) projects need it, at least not now. Convergence had already been naturally maintained.

• What should be the criteria for selecting people on the TB (if any)?

Contributor status should be a condition for the candidate-ship. As proposed, the group is not a M(anagement)B, but a TB. So, as in-depth knowledges as possible should be required.

• Who have voting rights when we vote on candidates for the TB?

Considering the above note, everybody interested. Maybe, related would be (probably obvious, but not to me) how we'd vote?

• What should be the term for a TB member?

Would it be a per member or per board term? (If one member leaves, the one to take his place stays in for how much longer?).

I would propose a _first_ 1 year limit. This way we could see how/if it works.

Also, what would this number be? 3 or 5 (considering the tie resolution solution already proposed and the "small" suggestion)?

I'd like 5, for some fresh air. ;-)

• Should this TB handle any issues beyond development? (ex. website

content, iptel.org in the wider SIP context, relationship with other projects, packaging, longer-term positioning of projects, longer-term development goals, and so on)

Not, if TB. I bet a lot of skilled folks don't have a clue about websites ratings or don't want to know what libs can be used on whatever distribution/OS.)

• If not, do we need another group that could handle such things?

No. IMO, the projects needs (back?) a larger community, not who should manage this community. To me it seems things are moving slow but in a good direction, as they are.

<troll'ish> Probably one could propose a list of goals, but without the contributors to provide them they'll stay in for nothing. Thus, I would already provide the first goal criteria: make it sexy for developers (users are necessary but not enough); if some guy wants to do outrageous things with SER (like, say, IMS :)), or OO-like cfg or colors in logs or whatever), let him do that, provided the robustness is kept. Its much more likely to get good quality code if one has were to choose from; if code is lousy, it'll get filtered out in time.

The other way, as it seems, is to go split ways (the first two larger ones are named starting with "Open" ...), and having code moved back and forth is just ridiculous (besides not durable). </troll'ish>

Regards,