Hi Folks!
inline...
2007/4/12, Greger V. Teigre <greger(a)teigre.com>om>:
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.
Great movement!!!!
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?
I think
there should one for each project (SER,SEMS,SERweb). I don't
think a lonely TB would manage everything and personally I belive in
specialization.
There's however one important thing missing: modules! Due to SER's
architecture with lots of modules probably the module's creator should
have some decisions on his/her module.
* What should be the criteria for selecting people on
the TB (if any)?
I'm fine with Greger's proposal.
* Who have voting rights when we vote on candidates
for the TB?
I think CVS rights are a really good approach.
* What should be the term for a TB member?
I'm fine with Greger's proposal. 2 year seems reasonable
* 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?
Each TB should focus on technical aspects and another group
(consultant, management,whatever name you prefer) should focus on
these other aspects. This group must also ensure comunication between
the different
iptel.org projects so they keep compatibility.
Other things this group should do is publishing more complex routing
scripts showing the power of the diferent projects. I'm sure lots of
nice features are unknown...
Best regards,
Greger
_______________________________________________
Semsdev mailing list
Semsdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/semsdev
My final picture would be a MB (Management Board) focused on
non-technical aspects and coordination between projects.
One TB (Technical Board) for each project, resulting in 3 of these groups.
In the voting process, the module creator should have a vote in those
decisions affecting his/her module. By this voting process I mean the
"meeting" of the TB when it's not possible to reach an agreement on
the mailing list.
My fast 2 cents,
Samuel.