Public SourceMage Discussion List

[Hamish Greig <hgreig AT bigpond.net.au>]

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

On Mon, 19 Apr 2004 06:39, Seth Alan Woolley wrote:
> Why didn't you explain things so cogently before?  My response is below:
>

I did. This is just a repeat of everything I have said before. If what I 
wrote 
before was not read or was misunderstood I assume it was because I was so 
outraged.
I am responding to some points for clarification.

<snip>
> > 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.
>
> This goes without saying.

I think so and you think so. But it did happen.

>
> > 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.
>
> I believe the person who you are referring was being honest about the
> situation, at least to me.  I can't vouch for private communications.  I
> understand your issues with some lack of progress, although, maybe my
> perspective is different -- there was progress, although you may not
> have liked the rate and quality of releases, we've had similar rate and
> quality in that aspect for a while.  It's true that there wasn't an
> increase in the rate of progress, but some progress was made.

lack of progress is fine, I understand how volunteer duties come last in 
life. 
What I do not accept is that I had to reopen so many bugs when I finally took 
over, bugs don't get closed because the owner doesn't have the skills to fix 
them, they need to ask for help in that case. Nor do I accept that for more 
than six months we were "publically" told things were hard, but were 
progressing ok, and next we new the major project was closed, with nothing 
achieved and no time left to make it work. There is a difference here and it 
shouldn't be altered by perspective. I think this behaviour is inexcusable, 
admitting to problems in june last year would have given everyone interested 
a chance to help (or take over the role).

> > 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.
>
> Why is it every group I'm in has conflict?  Oh, that's natural.
> Anyways, it seems you are asking for a Constitution with some
> explanation of defined roles.  Do you have a draft in mind?  Let's try
> to keep bylaw materials out of the Constitution as well.  I always say,
> if you want to see change, prepare to be the source of that change, or
> at least, prepare to do concrete work to see the change eventually
> happen, even if it requires help from others.
>

Yes it is natural to have some sort of conflict. How conflict is dealt with 
is 
important though. 
"I am "<insert title here>", what I say goes ! " is not any sort of 
resolution, after that happened I had few options left apart from abusing the 
power I had as ISO lead and witholding my support for the release.
It should never have got to that stage.

> I believe we've all been open to a Constitution.  Anybody want to help
> write one?
>
> > 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.
>
> This type of stuff is usually handled by a paid volunteer coordinator in
> most non-profits.  We can't pay anybody, so we can have a volunteer
> volunteer coordinator.  Is that what Project Leader means?  Maybe we
> need to remove the Project Leader position and have a Volunteer Lead
> position that handles these aspects.  This flattens somewhat the
> structure of the group and it turns that single point of failure into a
> committee of team leads, all able to second-guess each other.
>
> How many people feel that a project leader is really necessary?
>
> > 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.
>
> I can understand that the dated-deadline issue is a matter of opinion
> currently.  I think certain groups can work in either dated or undated
> deadlines.  I know this doesn't apply to us, but I'm in some groups that
> have required filing periods for things.  Missing a deadline often
> carries a heavy fine.  Also, when I edited my High School Year Book, we
> had deadlines, or we wouldn't have been able to publish.
>
> On software, though, I agree with you, that dated deadlines are often
> more counterproductive than they produce.  Having no dated deadlines in
> all circumstances, however, might be going a bit too far.  If we had a
> non-profit committee for handling that type of thing, we'll have to have
> deadlines, for example.
>
> > 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.
>
> Let's be careful, "bad behavior" can be interpreted widely and you might
> fall under your own rule here depending on who's doing the interpreting. ;)

sure, I know I haven't won any friends by being honest. And if that means I 
am 
a bad person I will live with that. 
I will no longer live with people not responding at all to direct comments to 
them in bugzilla, I will not live with being privately abused in response to 
factual bugzilla posts, i will not accept  that people wanting to add "SMGL 
developer" to their resume or CV can't spend a minimum amount of time a month 
to earn that priviledge, I will not accept everyones tacit allowance of the 
problems with individual people that led to the 1.0 delay and vote, nor will 
I ever find it acceptable that there is absolutely no accountability in this 
project.

> But back on point.  In training for volunteer coordination, they teach
> you to make job descriptions and assess the ability of the volunteer to
> be able to function at the level required.  The key is to put the
> volunteer in a position that is right for them.  This can often take a
> lot of work, especially if the volunteer thinks they are performing, and
> they aren't actually performing.  I would think they would like to dive
> right in, but in most non-profits, this isn't what works.  Starting in
> smaller things, even if they can handle more, might be the safest route
> to keep your volunteers longer.  It is always, of course, a judgement
> call of the volunteer coordinator (or committee).
>
> > 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.
>
> I agree, this is a good plan.
>
> > 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.
>
> I think you kind of went about it the wrong way in tone for most
> developers to feel like taking a side.  I sincerely think this is what
> happened.  Also, I'm sure a lot of our developers are simply not ready
> and/or do not care for all the systems that you are proposing that could
> easily correct such situations.  Personally, I think it will be a
> problem even if there were things in place to address it, it only
> changes the degree to which the problems can mushroom, as they have now
> in your situation.

I guess that is the difference, IMO there is no excuse for what happened, it 
is unacceptable, and I am outraged. Outraged to the point I won't continue to 
work with the project.


>
> > Thanks and I think goodbye
> > Hamish Greig
>
> I'll miss you, Hamish.  Don't feel shy about coming back, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAgxdz8fSufZR6424RApB+AJ93bUQb+575XsUZ/XJhnpMme8SIiACfTCWi
tUkGMhw8qeXtO4fne9kkc+g=
=ZJv0
-----END PGP SIGNATURE-----