13 Apr
2007
13 Apr
'07
10:29 a.m.
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