[ubuntu-in] The Community Stucture
Baishampayan Ghose
b.ghose at ubuntu.com
Mon Mar 27 06:09:14 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vidya,
> 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.
Well, as you just pointed out, difference of opinion is commonplace in
all international projects. Ours will not be an exception. But I am yet
to see any project which has laid out rules/guidelines regarding
redressal. We will solve those issues as they are solved in all projects
... by discussing the issues on the list and on IRC. A special clause
for this is totally unnecessary IMHO.
> 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.
SSH access will only be given to those who require it. It's not some
kind of fruit or a prize which we are supposed to share equitably. The
job of a sysadmin is specialised and is not so heavy duty yet that we
need to have too many people in it.
The council will meet every fortnight to discuss issues. The IRC meets
will be open to all and will be logged. The agenda page will be put up soon.
> 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.
Yes, they are separate individuals. But, both kamion & elmo who are in
the CC are also core-developers and admins. Our project here is of much
smaller scale and I don't really understand how there can be conflict of
interest. And don't you think we are drifting a bit too much into this
who-gets-what-power other than concentrating on the work at hand?
> 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.
As I have said before, Colin Watson (kamion) & James Troup (elmo) are
both in the CC and are also Admins (not tech-board). Same with Scott &
Matthew. This is not a matter of _post_. It's work that has to be done.
Since it's a relatively new project with all new people, I recommend
that we go ahead with this, we can always revise our processes as and
when required.
> 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 :-)
Let me repeat, there is no hierarchy here. The Council exists because
there are a lot of things which can't be handled by individuals, or
can't be handed over to individuals. Since it's a new team, we don't
even have many members, leave alone people who can lead and take up
work. The job of the Council is to oversee the operations and hand-hold
all the people who are new to this business. The existence of the
council has nothing to do with the participation of more people in this
project.
> 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.
Competence can be gained with experience and trust by participation. We
are mentoring newbies in this project, but it's just out of the scope of
the project to mentor people at sysadmin skills. if you check the
work-assigned list here https://wiki.ubuntu.com/IndianTeam/TODO, you
will see that at least three people are absolute newbies to this type of
work. We are doing this because we want more people to come in. Who
admins the server is totally unrelated to this. And one more thing,
please don't confuse the Technical Board with the Admin team. The admin
team here is more like the Ubuntu Core-Developers' team. We don't have
enough people yet to think about elections at every step. Our goal at
the moment is to fix all Indic issues before Dapper. I recommend we
concentrate on that instead of indulging in useless political theories,
etc. We are not here to hold power in our hands. We are trying to
scaffold the project in its initial stages. The day when I will get 10
worthy nominations for the Council membership, I will resign from the
Council and get back to my usual work.
> 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, we intend to advertise soon. We have just recently concluded a poll
regarding the website. Once we have our site up and running, we will do
that. I have no issues if people make mistakes in projects etc. since
there are people to mentor them. Why don't you take up the task of
identifying what is to be done before Dapper and hand them over to the
willing people? We have already compiled a list in our TODO &
IndicPackages pages.
> 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.
I agree with that. We are all for openness. But that doesn't necessarily
mean a lack of structure, something like ``Take any job and do it in
whatever way you can, or leave it in whatever state you want to. No need
to tell what you have done and how''. I agree that this is a Free
Software project, but such projects don't really work well in a
Democratic fashion. There has to be somebody who will hold the reins and
lead by example.
> Feel free to (dis)agree and do spare a few moments to review, comment
> and state your thoughts !
Yeah, that's what I just did!
Regards,
BG
- --
Baishampayan Ghose <b.ghose at ubuntu.com>
Ubuntu -- Linux for Human Beings
http://www.ubuntu.com/
1024D/86361B74
BB2C E244 15AD 05C5 523A 90E7 4249 3494 8636 1B74
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEJ3N6Qkk0lIY2G3QRAsDyAJ9WIaF8VKZfuT6QcxG0waHnphYkzgCgseZS
+AUuTMe9izU/a7ixeCZjOcY=
=8UcC
-----END PGP SIGNATURE-----
More information about the ubuntu-in
mailing list