Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Admin meetings

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] Admin meetings
  • Date: Sun, 18 Apr 2004 23:45:35 +1000

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

After a private discussion "off-list" it is apparent I need to explain my
intentions here. I do not expect any apologies from anyone for their mistakes
or failures in their positions last year. The specific mistakes and failures
are not points for debate, they are in the past, nothing can be done about
them now.

In any project, lack of planning and cooperation is deadly, and regardless of
our status, as volunteers or as paid professionals, we all need to act
professionally and communicate our work, our abilities, our problems and our
goals, or there is no project, only a few hard working individuals whose
paths hopefully intersect.
My choice of "Admin meeting" as a topic to bring this up one last time is
because within that simple heading falls several main points.

1) awareness of developer activity and how that affects communication, goal
achievement and project morale. A person can't lead without knowledge of the
people he hopes to lead and nor should a developer be allowed to ignore the
work of his fellow developers. Subscribing to perforce notices, or cvs
notices when it is setup, should become mandatory.
2) dishonesty about activity or progress and not communicating any problems
in
a timely fashion, so that the situation can't be salvaged, should be
unacceptable and recorded as such.
3) delineation of management roles, boundaries for people willing to fill the
lead roles and some recorded method of conflict resolution, so no single
person is capable of "leading" the project astray.
4) supervision is necessary in any project, for without supervision and
accurate assignment of jobs (according to peoples capabilities), poor
workmanship will ruin a lot of other peoples good work. Accordingly,
positions should be filled when someone with the qualifications applies, not
because they are a nice guy or they have been around for "ages", only when
they are proven capable of doing the job.
5) making sure the roadmap has regular achievable goals, doesn't use dated
deadlines and always reflects the current developers wishes, so it is
adaptable, up-datable, understandable in its simplicity and always relevant
to current developers.
6) recording some policies for acceptable behaviour, accountability for bad
behaviour or submissions, minimum expectations of developers and whether they
should become requirements for volunteering.

My reasoning for this is not to crucify any single person, but instead to
draw
attention to the problems, in the hope that you will discuss how they came to
be, make some simple adjustments to the social contract (and if necessary
make some new documents) to stop them from ever happening again.
My own work on the ISO recently has been over-shadowed by this, because in an
effort to correct the problems of the last year, in continuing my
contributions on the ISO, I was compromising my own standards and ethics on a
daily basis. It was obvious all my previous emails had not succeeded in
starting discussion about any new procedures or guidelines that would stop
the same thing from happening to some other active developer in the future.
I think what happened is inexcusable and unacceptable and am leaving because
of it, hopefully you too recognise the problems here and will safeguard
against it ever happenning again. If you don't feel as strongly about these
issues as I do, at least I can retire knowing I did every thing I could.


Thanks and I think goodbye
Hamish Greig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAgoaC8fSufZR6424RApc/AJ9LXguIyrdWXIGlaVjL5sFPGUnjtwCfUgeW
nvjMMto61i5UzZIHxkm5E+o=
=zhjt
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page