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