12 Apr
2007
12 Apr
'07
9:46 a.m.
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
12 Apr
12 Apr
9:54 a.m.
New subject: [Serusers] Re: [Serdev] IMPORTANT: Invitation to discuss the management of iptel.org
Below are my personal opinions on the open issues I listed.
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'm not
sure what I think here. I see pros and cons.
* What should be the criteria for selecting people on
the TB (if any)?
I think everybody should be allowed to put forward names.
* Who have voting rights when we vote on candidates
for the TB?
Hopefully we can agree to a set of good candidates without resorting to
formal voting, but if there is disagreement about controversial
candidate(s), I think maybe those with CVS write access should be
allowed to vote.
* What should be the term for a TB member?
We
need some continuity, one year seems too short, three years too long.
What about two?
* 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)
No, I don't think the people on the technical
board will be the best
people for doing such stuff.
* If not, do we need another group that could handle
such things?
Yes, but I don't think this group should have any formal decision
power
and that it thus can be more informally put together?
g-)
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.
11:07 a.m.
New subject: [Serusers] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
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.
13 Apr
13 Apr
10:29 a.m.
New subject: [Serusers] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
Greetings,
Greger V. Teigre wrote:
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 would incline to a No. I'm not yet convinced that all (other) projects
need it, at least not now.
Convergence had already been naturally maintained.
* What should be the criteria for selecting people on
the TB (if any)?
Contributor status should be a condition for the candidate-ship. As
proposed, the group is not a M(anagement)B, but a TB. So, as in-depth
knowledges as possible should be required.
* Who have voting rights when we vote on candidates
for the TB?
Considering the above note, everybody interested.
Maybe, related would be (probably obvious, but not to me) how we'd vote?
* What should be the term for a TB member?
Would it be a per member or per board term? (If one member leaves, the
one to take his place stays in for how much longer?).
I would propose a _first_ 1 year limit. This way we could see how/if it
works.
Also, what would this number be? 3 or 5 (considering the tie resolution
solution already proposed and the "small" suggestion)?
I'd like 5, for some fresh air. ;-)
* 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)
Not, if TB.
I bet a lot of skilled folks don't have a clue about websites ratings or
don't want to know what libs can be used on whatever distribution/OS.)
* If not, do we need another group that could handle
such things?
No. IMO, the projects needs (back?) a larger community, not who should
manage this community. To me it seems things are moving slow but in a
good direction, as they are.
<troll'ish>
Probably one could propose a list of goals, but without the contributors
to provide them they'll stay in for nothing.
Thus, I would already provide the first goal criteria: make it sexy for
developers (users are necessary but not enough); if some guy wants to do
outrageous things with SER (like, say, IMS :)), or OO-like cfg or colors
in logs or whatever), let him do that, provided the robustness is kept.
Its much more likely to get good quality code if one has were to choose
from; if code is lousy, it'll get filtered out in time.
The other way, as it seems, is to go split ways (the first two larger
ones are named starting with "Open" ...), and having code moved back and
forth is just ridiculous (besides not durable).
</troll'ish>
Regards,
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
20 Apr
20 Apr
3:20 a.m.
New subject: [Serusers] Re: [Sems] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
Hi!
as for the small number of participant in the SEMS project, i'm convinced that
we do not need such a board for SEMS by now. Stefan and I are just ruling
this world and i like strong central administration ;-)
Cheers
Raphael.
On Friday 13 April 2007 16:29, Bogdan Pintea wrote:
Greetings,
Greger V. Teigre wrote:
--
Dipl. Inf. Raphael Coeffic
iptelorg GmbH
Am Borsigturm 11
13507 Berlin
Germany
rco(a)iptel.org
www.iptelorg.com
T +49-30-3251-3218
F +49-30-6908-8248
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 would incline to a No. I'm not yet convinced that all (other) projects
need it, at least not now.
Convergence had already been naturally maintained.
* What should be the criteria for selecting
people on the TB (if any)?
Contributor status should be a condition for the candidate-ship. As
proposed, the group is not a M(anagement)B, but a TB. So, as in-depth
knowledges as possible should be required.
* Who have voting rights when we vote on
candidates for the TB?
Considering the above note, everybody interested.
Maybe, related would be (probably obvious, but not to me) how we'd vote?
* What should be the term for a TB member?
Would it be a per member or per board term? (If one member leaves, the
one to take his place stays in for how much longer?).
I would propose a _first_ 1 year limit. This way we could see how/if it
works.
Also, what would this number be? 3 or 5 (considering the tie resolution
solution already proposed and the "small" suggestion)?
I'd like 5, for some fresh air. ;-)
* 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)
Not, if TB.
I bet a lot of skilled folks don't have a clue about websites ratings or
don't want to know what libs can be used on whatever distribution/OS.)
* If not, do we need another group that could
handle such things?
No. IMO, the projects needs (back?) a larger community, not who should
manage this community. To me it seems things are moving slow but in a
good direction, as they are.
<troll'ish>
Probably one could propose a list of goals, but without the contributors
to provide them they'll stay in for nothing.
Thus, I would already provide the first goal criteria: make it sexy for
developers (users are necessary but not enough); if some guy wants to do
outrageous things with SER (like, say, IMS :)), or OO-like cfg or colors
in logs or whatever), let him do that, provided the robustness is kept.
Its much more likely to get good quality code if one has were to choose
from; if code is lousy, it'll get filtered out in time.
The other way, as it seems, is to go split ways (the first two larger
ones are named starting with "Open" ...), and having code moved back and
forth is just ridiculous (besides not durable).
</troll'ish>
Regards, 
22 Apr
22 Apr
9:07 p.m.
New subject: [Serusers] Re: [Serdev] Re: [Sems] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
Hello,
Raphael Coeffic wrote:
Hi!
as for the small number of participant in the SEMS project, i'm convinced that
I am just wondering why the number is so small, why there are not more
people contributing. Either no one except us is using it, or people do
not see clearly how the project is managed and therefore do not have
enough trust in the project to contribute. Maybe a more clearly defined
and stated contact and TB person would help here.
I would simply propose Raphael as TB member, then he can also coordinate
things concerning SER/SEMS.
Stefan
we do not need such a board for SEMS by now. Stefan
and I are just ruling
this world and i like strong central administration ;-)
Cheers
Raphael.
On Friday 13 April 2007 16:29, Bogdan Pintea wrote:
--
Stefan Sayer
Media Services Development
stefan.sayer(a)iptego.de
www.iptego.de
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
Greetings,
Greger V. Teigre wrote:
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 would
incline to a No. I'm not yet convinced that all (other) projects
need it, at least not now.
Convergence had already been naturally maintained.
* What should be the criteria for selecting
people on the TB (if any)?
Contributor status should be a condition for the
candidate-ship. As
proposed, the group is not a M(anagement)B, but a TB. So, as in-depth
knowledges as possible should be required.
* Who have voting rights when we vote on
candidates for the TB?
Considering the above note, everybody interested.
Maybe, related would be (probably obvious, but not to me) how we'd vote?
* What should be the term for a TB member?
Would it be a per member or per board term? (If one member leaves, the
one to take his place stays in for how much longer?).
I would propose a _first_ 1 year limit. This way we could see how/if it
works.
Also, what would this number be? 3 or 5 (considering the tie resolution
solution already proposed and the "small" suggestion)?
I'd like 5, for some fresh air. ;-)
* 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)
Not, if TB.
I bet a lot of skilled folks don't have a clue about websites ratings or
don't want to know what libs can be used on whatever distribution/OS.)
* If not, do we need another group that could
handle such things?
No. IMO, the projects needs (back?) a larger community, not who
should
manage this community. To me it seems things are moving slow but in a
good direction, as they are.
<troll'ish>
Probably one could propose a list of goals, but without the contributors
to provide them they'll stay in for nothing.
Thus, I would already provide the first goal criteria: make it sexy for
developers (users are necessary but not enough); if some guy wants to do
outrageous things with SER (like, say, IMS :)), or OO-like cfg or colors
in logs or whatever), let him do that, provided the robustness is kept.
Its much more likely to get good quality code if one has were to choose
from; if code is lousy, it'll get filtered out in time.
The other way, as it seems, is to go split ways (the first two larger
ones are named starting with "Open" ...), and having code moved back and
forth is just ridiculous (besides not durable).
</troll'ish>
Regards, 
23 Apr
23 Apr
12:30 a.m.
New subject: [Serusers] Re: [Serdev] Re: [Sems] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
two votes for Raphael as a TB member :)
-A
* Stefan Sayer <stefan.sayer(a)iptego.de> [070423 03:08]:
Hello,
Raphael Coeffic wrote:
Hi!
as for the small number of participant in the SEMS project, i'm convinced that
I am just wondering why the number is so small, why there are not more people
contributing. Either no one except us is using
it, or people do not see clearly how the project is managed and therefore do not have
enough trust in the project to
contribute. Maybe a more clearly defined and stated contact and TB person would help
here.
I would simply propose Raphael as TB member, then he can also coordinate things
concerning SER/SEMS.
Stefan
we do not need such a board for SEMS by now.
Stefan and I are just ruling this world and i like strong central
administration ;-)
Cheers
Raphael.
On Friday 13 April 2007 16:29, Bogdan Pintea wrote:
>Greetings,
>
>Greger V. Teigre wrote:
>>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 would incline to a No. I'm not yet convinced that all (other) projects
>need it, at least not now.
>Convergence had already been naturally maintained.
>
>>* What should be the criteria for selecting people on the TB (if any)?
>Contributor status should be a condition for the candidate-ship. As
>proposed, the group is not a M(anagement)B, but a TB. So, as in-depth
>knowledges as possible should be required.
>
>>* Who have voting rights when we vote on candidates for the TB?
>Considering the above note, everybody interested.
>Maybe, related would be (probably obvious, but not to me) how we'd vote?
>
>>* What should be the term for a TB member?
>Would it be a per member or per board term? (If one member leaves, the
>one to take his place stays in for how much longer?).
>
>I would propose a _first_ 1 year limit. This way we could see how/if it
>works.
>
>Also, what would this number be? 3 or 5 (considering the tie resolution
>solution already proposed and the "small" suggestion)?
>
>I'd like 5, for some fresh air. ;-)
>
>>* 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)
>Not, if TB.
>I bet a lot of skilled folks don't have a clue about websites ratings or
>don't want to know what libs can be used on whatever distribution/OS.)
>
>>* If not, do we need another group that could handle such things?
>No. IMO, the projects needs (back?) a larger community, not who should
>manage this community. To me it seems things are moving slow but in a
>good direction, as they are.
>
>
><troll'ish>
>Probably one could propose a list of goals, but without the contributors
>to provide them they'll stay in for nothing.
>Thus, I would already provide the first goal criteria: make it sexy for
>developers (users are necessary but not enough); if some guy wants to do
>outrageous things with SER (like, say, IMS :)), or OO-like cfg or colors
>in logs or whatever), let him do that, provided the robustness is kept.
>Its much more likely to get good quality code if one has were to choose
>from; if code is lousy, it'll get filtered out in time.
>
>The other way, as it seems, is to go split ways (the first two larger
>ones are named starting with "Open" ...), and having code moved back and
>forth is just ridiculous (besides not durable).
></troll'ish>
>
>
>Regards,
--
Stefan Sayer
Media Services Development
stefan.sayer(a)iptego.de
www.iptego.de
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
Sems(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/sems 
2:31 a.m.
New subject: [Serusers] Re: [Serdev] Re: [Sems] Re: [Semsdev] IMPORTANT: Invitation to discuss the management of iptel.org
On Mon, Apr 23, 2007 at 06:30:56AM +0200, Atle Samuelsen wrote:
two votes for Raphael as a TB member :)
-A
My votes goes also to Raphael :-)
* Stefan Sayer <stefan.sayer(a)iptego.de> [070423 03:08]:
> Hello,
>
Wbr,
--
Alexandr Dubovikov * baron@iRC RusNet * mailto:shurik@start4.info
AD1-UANIC * ICQ: 122351182 * http://www.start4.info
P.S. sorry, I am so inactive now :-(. Too many projects in the queue...
2:46 a.m.
New subject: [Serusers] TB votes
Hi!
thanks for the votes! I guess i'll have to take my responsabilities ;-)
Cheers
Raphael.
On Monday 23 April 2007 08:31, Alexandr Dubovikov wrote:
On Mon, Apr 23, 2007 at 06:30:56AM +0200, Atle
Samuelsen wrote:
two votes for Raphael as a TB member :)
-A
My votes goes also to Raphael :-)
* Stefan Sayer <stefan.sayer(a)iptego.de>
[070423 03:08]:
> Hello,
Wbr, 
6265
days inactive
6276
days old
10 comments
9 participants
participants (9)
-
Alexandr Dubovikov -
Atle Samuelsen -
Bogdan Pintea -
Greger V. Teigre -
olivier.taylor -
Raphael Coeffic -
samuel -
sip -
Stefan Sayer