Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

Why didn't you explain things so cogently before?  My response is below:

On Sun, Apr 18, 2004 at 11:45:35PM +1000, Hamish Greig wrote:
> 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.

That latter phrase is kind of how this group has been structured.  I'm
not sure if the structure that does exist would like to see much change
in this.

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

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

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

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

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.

> Thanks and I think goodbye
> Hamish Greig

I'll miss you, Hamish.  Don't feel shy about coming back, though.

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8  3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgpww7duEXc0_.pgp
Description: PGP signature