12 Apr
2007
12 Apr
'07
10:56 a.m.
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(a)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.