[ubuntu-in] The Community Stucture

vid svaksha at gmail.com
Fri Mar 24 17:27:50 GMT 2006


On 3/24/06, Baishampayan Ghose <b.ghose at ubuntu.com> wrote:
>
> There is no clause which says about ``removal'' of a community
> volunteer.

{this part was written before I saw the next mail, so ignore}

Notre Bene: Lines 39 and 37 were changed after my mail {sent Mar 24
02:30:15 GMT 2006} to this list This is self-evident in the
differences[0](*) dated 2006-03-24, between revisions 11 and 12
(04:16:13 GMT) and 13 (2006-03-24 04:22:34).

[0] https://wiki.ubuntu.com/IndianTeam/Structure?action=diff&rev2=12&rev1=11
(*) Those interested can check the Revision history by clicking on the
"Get Info" link at the top of the wiki page.



> I agree that the
> draft says nothing about this removal issue. We will add this extra
> clause which will say that the CC won't remove anybody arbitrarily
> without discussing with the community members and without assigning
> valid reasons.

That sounds nice. I have some suggestions which are mentioned below as
the wiki was not supposed to be edited.



> > [1] Redressal clause - There is no mention of this in the wiki draft.
> >  In the event that any IN-volunteer has grievances how would the
> > IN-Council Members solve the same. Would redressal avenues be open to
> >  all or restricted to Council Members and Admins.
> What kind of grievances are you talking about? What can possibly be the
> grievance of a project member? I have no idea what are you talking
> about. Kindly provide some examples to clarify.

Anyone involved in international projects will know that differences
in opinion are a part of all projects. Don't you agree that its
*extremely off-topic* to quote names or specific examples on this
list. Folks requiring specific examples and/or details are free to
read old mailing list archives and IRC logs that are publicly archived
for most International Linux communities.

I understand and agree fully that ssh access should be restricted to
administrators and mentors/mentee working on specific projects.
However, for example, if an IN-team member's commits, mail or web
space on ubuntu-in.org has been revoked. How do we address this or any
other issues? Also, how many times a month will the Council meet to
discuss issues. Will the IRC meetings be open to all or not ? If there
is an an Agenda page listing the times and date, the wiki-draft does
not link it.



> know how there will be a conflict of interest here as all members of the
> Ubuntu Technical Board are also admins of the repos and even a few
> members of the Ubuntu CC are core-developers and thus admins.

I opine that, Loco-teams are a team of volunteers under the aegis of
Ubuntu and not Ubuntu in itself and any comparison would not be in
similar vein.  Albeit if one still seeks a comparison, then it is
interesting to note that, all members of the Technical board[1] and
Community Council[2] are *separate* individuals, with the exception of
Mark Shuttleworth. Also note that, CC validity is 2 years and Tech
term is for 1 year after which nominations are confirmed by vote.

/quote (last para from the Council page)----
The discrepancy between the terms of appointment to the Community
Council (two years) and the Technical Board (one year) is deliberate.
The Community Council is the more philosophical body, and is intended
to take a more measured, deliberate approach to the problems of
community organisation than the Technical Board, which must deliver a
new set of Technical Policy updates for each release.
/unquote------------

[1] http://www.ubuntu.com/community/processes/techboard
[2] http://www.ubuntu.com/community/processes/council

Further to the above explanation, it is a conflict of interest simply
because a single person holding *two* posts of Admin and Council
member gets absolute power in decision making. Hence the equitable
balance by separation of power across different people as followed by
Ubuntu peers which is sensible and fair don't you think.

In the draft it is not clear how we will manage the size of the
Council Members if core decisions have to be made. Hence a task-based
team would be better equipped for the job. To avoid any confusion a
flat community structure with different teams of people handling
various tasks seems better.  In an earlier email I had cited the
example of the Italian team. Unlike a tiered model they have a flat
and simple structure with a working team for different tasks which
effectively balances and most importantly, IMHO, will ensure a larger
participation of Ubuntu volunteers in India which is Aim#2 on the
Indian Team page after all :-)






> Furthermore, the admin job can't be given to anybody since there is a
> matter of trust & competence involved here.

Its outside the purview of this discussion to define *abstract* 
values like trust & competence. Baishampayan, you have volunteered to
mentor newcomers on the UW list so why not extend that to Ubuntu-IN
too.
As followed by Ubuntu peer, fix separate terms for Council (2 years)
and Tech (1 year). All posts should be up for review and voting.
Despite all these proactive steps if no volunteer has stepped up for
the said task/s, then work can be reassigned after the usual voting
procedure in the next election.



> Ubuntu volunteers are 100% allowed to participate. In fact, Ubuntu
> members are automatically elected into the Council. Admin posts will not
> be renewed all the time. We will assign admin jobs to new people from
> the Council as and when required.

True, people will step-up *only if they know* that there exists a need
for volunteers. See above... about mentoring. That is why all tasks
(locales, translations, Indic projects, etc...) should be advertised
on the mailing list and web-site regularly. Yes, I am very well aware
that people make mistakes, but a major blunder (if unresolved locally
or not satisfactory to all parties concerned) could always be
escalated to the main Ubuntu Council for further action. The wiki-page
or main page should have links on how people can do that.



> Yes, they will be. Once the structure is in place all the meeting logs
> will be put up somewhere and as far as the policy formation is
> concerned, I don't think it's necessary since the very facts that it has
> been accepted by all and that it has been peer reviewed, also means that
> the whole community was involved in the drafting process. Correct me if

IMHO, silence can mean different things to different people. Also
people come and go in various projects and we can keep processes
transparent and documented for future volunteers (and current ones
too) who should have access to this information. If openness exists in
peer structure it makes a lot of sense to follow the same practice in
the IN-loco team too.

Feel free to (dis)agree and do spare a few moments to review, comment
and state your thoughts !

Thanks for reading !
--
Vid


More information about the ubuntu-in mailing list