Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Re: [SM-Admin] Source Mage admin meeting - 07 March 2004, 1400 GMT

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Hamish Greig <hgreig AT bigpond.net.au>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Re: [SM-Admin] Source Mage admin meeting - 07 March 2004, 1400 GMT
  • Date: Tue, 2 Mar 2004 23:39:47 +1100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 2 Mar 2004 21:56, Unet wrote:
> Moreover, annoucing a new project lead without
> _any_ concertation at all is not really conceivable, and it is, in my
> point of view, not acceptable at all. AFAIK we're not in Haiti. We all
> stated that we believed in a democratic process, and it is by this
> process that you have been chosen for project lead, a task you
> brilliantly performed, _almost_ to its conclusion.
>

I agree.
I have known of this decision for a while but in light of recent problems
with
project communications I now think all team leaders should be democratically
chosen/voted. It is not enough just to want to do a job, you must also agree
to discuss problems with other people, other team leads and respect the will
and desires of the community.
Nominations, nominees being seconded and actual voting is called for if this
project hopes to progress in accordance with the wills and desires of its
developers and users.
Finally, an open position doesn't need to be filled unless the right
candidate
applies, putting people into a role they are ill-equipped to handle will
cause more problems than solutions and should be avoided.

> > In the last few months there has been some decisions made behind the
> > scenes which involved the Team Leads and myself to appoint a replacement.
> > The replacement has been informed, has agreed and is ready to take
> > charge.
>
> Again, this is not acceptable. Decisions as important as this one should
> be made public, not 6 days before the deadline, and most certainly not
> with a "ready-made" solution. I do not want to be in a situation where
> people are coopted by few (call that an oligarchy). This has nothing to
> do with the persons involved, but rather in the concept of it. If we are
> trying "not to hide problems" (as stated in our social contract, but for
> technical problems), let's try not to hide solutions :)
>

The person currently slated for the project lead position has my support, but

in spite of this, I agree it is contrary to our social contract to have it
decided by the outgoing lead and his cronies.
I agree with Kevin and would like to formalise my support with a democrat
method.
I think for the same reasons stated (by Kevin and me both here and
previously)
that team leads should also be democratically installed. Whether I will
continue to use SMGL depends on whether team leads will allow discussion of
problems in their chosen product.
I see no reason to continue contributing the 20-30 hours a week I have
contributed for the last year if my work in the grimoire and ISO is
completely dependant on a sorcery that users or developers cannot discuss
objectively with it's team members, and that doesn't respect the developers
that use it's product.
I wish it were just a personality conflict, but recent events and emails
( both private and public) show it is more fundamental than that.

> What I really think is that this meeting should be the moment when we
> will have to _vote_ for someone to take the project lead. I do not care
> about whether the issue of the vote will give the same result as your
> arrangements - as stated above, this is not the point. I will feel (and
> hopefully some people too) much more at ease after a vote than a
> designation.

I think a vote will show support for the currently nominated person, but it
still needs doing. It is the right way to move forward out of the current
problems.
Hamish

ps I say "team" because one bad apple can spoil the whole barrel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFARICW8fSufZR6424RAmtHAJ9uelqqw59khbHAM+j15J11FwpH3ACfTlK9
30p1LZgjPRnZnEsAe/2YdaQ=
=uxig
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page