[Serusers] IMPORTANT: Invitation to discuss the management of iptel.org

sip sip at arcdiv.com
Thu Apr 12 16:56:06 CEST 2007


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 at 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. 



More information about the sr-users mailing list