Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

On Friday 19 January 2007 23:56:48 Jeremy Blosser wrote:
> Disclaimer: These are some first thoughts and will probably be somewhat
> stream-of-consciousness, but you may as well know where I am now.  I
> reserve the right to change my mind between now and Feb 1.  Oh, also, this
> is really long, but you didn't expect me to be brief, did you?
<snip>

Short posts are easier to read during free time, and then reply. ;)

> ============================================================
>
> Less brief:
>
> 1) Get Things Done:
>    a) As I mentioned before, I will be setting up regular meetings pretty
>       far in advance, and we will meet on those dates.  I don't really care
>       what percentage attend or if we decide a lot at the meetings, my goal
>       is just to have set times we regroup and make sure we're heading in a
>       vaguely similar direction.  I want to avoid the situation where
>       someone says "we haven't had a group discussion in 6 months and I
>       have no idea what anyone else is doing".
>
>       I am tentatively planning to do these every 3 months for now, on the
>       3rd or 4th weekend of the month.  Probably Feb/May/Aug/Nov.  If they
>       start out well and we want more we can look at that, but this would
>       be the minimum.  Look for more info later.

Every three months should work out, but I found the main problem was getting 
everyone there and at a not too inconvenient time (it was 9AM for me on 
Sunday, but 3AM for others on Monday :/). We also had better results doing a 
discussion thread on the ML than trying to figure something out on IRC, 
though when we did, it went a lot faster. :)

Another idea is to have weekly or (more likely) monthly reports from the 
Leads 
on what they and their teams are doing, what's left to be done, and what help 
they might need.

>    b) I will be pulling together a "PL's List of Projects" page on the wiki
>       that will list all the major and minor things people say they are
>       working on, with an attempt to track priority, contributors, and
>       status of each.  I will use this list to try to help us focus groups
>       on a few projects at a time to get them done, then move on to others,
>       while not forgetting any of them.  Right now we spread out between
>       them all so thinly people burn out all over and nothing gets
>       finished.  Fair?

That is definately a good idea, and will help people see what's going on 
outside of the meetings.

My current list:
* SPARC port
* SMGL conversion script (http://smgl.sandall.us/projects/convert2smgl.html)
* Updating the Grimoire Guru Handbook (in tome/rdp.git)

>    c) For those things that just aren't working I will probably get pretty
>       blunt about dropping them.  The Drupal experiment still sounds good
>       in theory but if it doesn't step up soon I'm going to have a really
>       hard time leaving it on life support.

What part of the Drupal experiment are we lagging on? If it's just the part 
about moving the 'finished' documentation pages into DrupalBook, then we can 
always decide to use a Wiki for all documentation and continue to use Drupal 
for forums, news, etc.

>    d) I'm going to be holding those that do commit to doing things
>       accountable, especially Leads.  While it's a core tenet here that
>       people work on what they want to work on, and it's simple fact we
>       can't force anyone to get anything done, once someone commits to
>       doing something and others are depending on them I do think they
>       should get it done.  If they don't, they should at least lose any
>       prestige they got by agreeing to do it in the first place.  I'm the
>       first one I expect to be held to that standard, by the way.  I know
>       I'm behind on things already and if I don't catch up I expect you to
>       do something about it.

Definately how it should be. ;)

>       To this end I'll be requiring the Component Leads to give me details
>       on who they want making decisions for them when they are away,
>       whether assistants or the full Lead group or just me.  We *will* stop
>       being frozen by one person moving or losing connectivity or getting a
>       new job or being abducted by aliens or otherwise getting busy with
>       life.

Perhaps reimplement the Lead assistant position(s), and have Leads add people 
they trust to maintain their components as a component assistant?

>       For my part I will probably be appointing multiple APLs with
>       different focuses; like I said, I prefer to delegate things, and we
>       don't have enough people to afford a real hierarchy.

Will all APLs have the same authority with the focus being more a direction 
for their attention?
<snip>
>      One of those is the actual role of the PL, as I noted in a previous
>      message.  I want to see discussion on this, but my own pitch will be
>      to keep it fairly broad so the PL of the time can try what they think
>      works.  We mostly need to establish that the PL does have the
>      authority to act in the place of Component Leads who are away, though
>      I for one will be pushing to make clear that the PL only gets to do
>      that if a CL is actually gone; I want to keep an active CL the
>      authority over their own area apart from an actual vote overriding
>      them.

I'd prefer for the PL to have final veto status and able to make decisions 
for 
any component whose Lead is in any way incapable of making a decision.

Thanks for taking up the torch, Jeremy. :)

-sandalle

-- 
Eric Sandall                       | Source Mage GNU/Linux Developer
eric at sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/            | http://counter.li.org/  #196285

Attachment: pgpxEjx4O7PZf.pgp
Description: PGP signature