Skip to topic | Skip to bottom
Home
Sysadmin
Sysadmin.ListWorkPolicyGabar1.1 - 12 Mar 2005 - 00:31 - JiBetopic end
You are here: Sysadmin > ListworkWorkingGroup > ListWorkPolicy > ListWorkPolicyGaba

Start of topic | Skip to actions
Historical proposal, obsoleted by ListWorkPolicy.

Gaba' proposal

Something else to chew on... i wrote this some time ago intending to finish it with some more stuff, but I never got around to it...

What this email contains:

  • Background
  • Listwork today
  • What needs to be done * Proposal

Background

In San Fransisco many IMC people (majority of which were from the U.S.) met. I wanted to make it clear there that the method of operation that the tech team had been working under (as a growth of the rapid onslaught of demand and turn-around time) had been growing into a power structure that was unacceptable to the overall organization's (meaning the IMC) core. At that time things got done because certain people had access and certain people knew who to go to in order to get something done, it was a who you know sort of thing, instead of a sustainable process of involvement and transparancy. It was also the tech team making network-wide non-tech decisions. The message was heard and many of the decisions that the tech team had been making, have been organically growing into solid working groups (such as the new-imc working group). However, it is still true that a lot of the technical work gets done through the who-you-know system (which is really akin to the old-boys network), but this is changing.

Listwork today

Currently listwork is a functioning and healthy technical working group within the IMC network. There are some awesome people dedicated to making this piece of the IMC work. There is a process (granted, it is crude, but it is more advanced than many others) for some aspects, namely: How do you create a list? (http://newlist.indymedia.org), How do you get help with list related problems? (mail listwork). Little process is better than lots of process in my mind, because process can be crippling and beauracratic. That is not what we want, and if we ever get to that stage a revolution is required (revolution here is really just returning to what is important, reanalyzing what we are trying to do and evaluating our processes and our organization from the standpoint of our core values).

What needs to be done

In my mind, some simple processes and procedures need to be hashed out. Once these are done, I really believe that the listwork group will be the strongest working group within the IMC, but will be a model for other working groups to self-organize.

Proposal

I would like to propose that listwork consider the following issues, develop simple answers, without worrying about getting things perfect (as these processes should always be maliable), and adopt them as policy/procedures.

Defining process

How should proposals be submitted and handled?

Defining access

The listwork team, and a few system admins, have access to the new mail machine (sarai). It has been requested, and I think it is a valid request, although it isn't properly approved yet, that the only people who have access to sarai are those who are part of the listwork working group. This doesn't mean signing up for the mailing list and procmailing the list to a folder, never doing anything, this means active participation in the listwork group. Meaning, helping with list questions/problems/requests that are network-wide. In order to keep the rapid creep of root access down I think that this is a good policy, it doesn't make sense to punch huge holes in network-wide resource security for things that could simply be requested from a dedicated, strong working group (ie. listwork).

Defining boundries

  • How are new lists requested (done)
    • Of these list requests, what lists should be created?
    • How is the list creation process done (commands, who does it, notification that the list has been done)
    • What lists should be used for and what they should not be used for.

  • Roles of a list administrator
    • What is required
    • What to do when you dont want to be a list admin anymore

  • Roles of a listworker
    • What makes a listworker? (scope, expectations)
    • How to become a listworker (volunteer)
    • When you no longer can be a listworker

  • Emergencies
    • Problem notification
    • Resolution (ie. how should problems be worked?)

Here i will write some more proposal and try to make on from all of that.

-- JiBe - 12 Mar 2005 Created the page.
to top


You are here: Sysadmin > ListworkWorkingGroup > ListWorkPolicy > ListWorkPolicyGaba

to top

Copyright © 1999-2008 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding this tool? Send feedback (in English, Francais, Deutsch or Dutch).