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

[samuel]

Hi Folks!

inline...

2007/4/12, Greger V. Teigre <greger at teigre.com>:
> 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 at 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.