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

[Bogdan Pintea]

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