Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

Quoting Hamish Greig <hgreig AT bigpond.net.au>:
> 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.

Speaking of which I should probably set one up soon anyways. ;)
 
> 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.

I don't believe anyone disagrees with this one.

> 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.

People do make bad judgement calls and perhaps thought that they could do what
they said they would. We are only human.

> 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.

No one person has the power to lead this project astray as they were voted in,
and hence can be voted out, if needed. Also, all of the Leads (and developers
and users as well) can voice their opinions and be heard, so if anyone has a
problem, let us hear it so that we can work on it. As others have said,
however, be prepared to have some work ahead of you if you want to change
something.

> 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.

I don't believe we've ever put someone in a position just because they've been
with SMGL for a while, but instead we voted on who we thought would be best 
for
the position based upon our past experiences with them.

> 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.

Yes, yes, I still need to do that. :(
/me gives himself a kick

> 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.

Currently we just let someone know when the messup on a submission, usually
politely. ;) However, having requirements for official developers would be a
Good Thing(tm) IMO as we'd then have a process for removing them if they don't
meet them, instead of our sole process of, "Have they submitted in a while?".
Anyone care to writeup a minimum requirements list? If not, I'll see about
getting to it.
/me adds to his growing TODO

> 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.

Criticisms are welcome, especially when they help contribute to improving this
project. I thought that our Social Contract was basic enough to not be
overbearing, but if others feel the need to revamp it, then by all means let's
start a discussion on what needs changing in it.

> 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.

They had started discussions and so some procedures were changed, but perhaps
not all that you wanted. However, this group is made up of more than one
individual and with many ideas on How Things Should Be. If you feel that
something hasn't been done to your satisfaction, bring it up in a timely 
manner
(and preferably one thing per e-mail to make threading easy ;)).

> 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.

We're doing our best to do as we can. As has been said before, we only have so
much time to devote to SMGL, and that time fluctuates as RL takes precedence.
And if people want something changed they should submit some kind of "rough
draft" of their ideas as well, since discussion is all well and good, but a
starting point as such would be useful (this is in general, not to anyone
specifically).

> 
> Thanks and I think goodbye

Thanks for your hard work, Hamish, and give us a ring if you ever feel like
coming back.

> Hamish Greig

-sandalle

-- 
PGP Key Fingerprint:  FCFF 26A1 BE21 08F4 BB91  FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o?
K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++)
tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+
------END GEEK CODE BLOCK------

Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.