Leaders: -dev website sections

[Roger Dingledine <arma@seul.org>]

Simon will have a skeleton finished for the development part of the website
in the next few days.  Or at least, finished enough that other people
should start contributing, so we can actually get some content there in
addition to structure.  This means you guys should start coming up with
data that you should put in your section.  At a minimum, I'd like each dev
group to have

- Mission statement

  This is already written for you, in the seul-tasks document (draft
  available in http://web.mit.edu/arma/Public/seul-tasks. It's on the
  dev website as well, but I'm still mucking with versioning there.)
  except for seul-dev-ui and seul-dev-admin which hopefully Luka will be
  correcting soon. In any case, if your section is finished (the document
  will mention whether it is or not), please send me a comment (yay or
  nay) about it so I know you've read and acknowledged it. Also please
  correct and update your section, and indicate those corrections to
  swaldman@seul.org with cc to seul@seul.org.

- Active members

  Given the current situation, most of our developers are spread over
  multiple dev groups. We need more manpower before this section can become
  very large, but it's still a good idea to set it up now so people can get
  some exposure. Most active people should have accounts on cran, with
  homepages (or links) there. Even VERY sparse ones will do for now, but
  it should be standard.

- Archives

  This should be set up automatically on the page. You don't need to worry
  about it for now.

- Decisions and plans, in an easy to read/skim format

  This is one of the really important parts. We need to let people know
  what we've already decided so they don't keep starting up the same old
  threads. A FAQ for each dev group is a good idea.

  Think about the threads in your dev-list and how they were resolved.
  Consult the archives for help. Another legitimate way to solve this is to
  post to your dev group asking for a volunteer to do it (if it works...) Or 
  hand-pick a volunteer and see if he'll help.

  Try to pick out the major good posts from your list, so you can link to
  them from the dev page for "good reading". Or use them to build your FAQ.
  If we have somebody intelligent going through the archives, then we won't
  force random visitors to dig through piles of cruft for the useful posts.

  Simon adds:
  I've seen some very good FAQs that have simply consisted of a collection of
  mail or news postings carefully picked, perhaps with some commentary between
  them.  While a properly-written FAQ is undoubtedly better, this might be a
  method of getting one without too much effort.

- Past/Current/Future projects, with documentation, links, todo list,
  who's working on them, what sort of help they need

  Ok, so this is actually a lot of items. Once you've generated the list
  of threads and discussions from above, it should be pretty easy to
  figure out which ones should become projects in your dev group. They
  all have a status that you've already figured out too. And you know
  who's working on them, or at least who cares about them. Don't hesitate
  to email people personally asking if they'd be willing to take over that
  specific project, if their posts to your dev list made them appear
  competent and useful. For each project, try to come up with a todo list
  that will get it rolling, as well as a broad set of milestones and an
  eventual goal status. People tend to be much more willing to take on small
  tasks than large ones.

  Also of use for each dev group is a set of links to other places that can
  provide information about that group's goals and concerns. The UI dev group
  would have tons of links to gnome/kde/qt/freeqt/etc groups. The admin
  dev group would have links to coas, cron issues, packagers, linuxconf,
  etc. The help dev group would have links to xhelp, info, man, netscape,
  the gnome help thing. The apps group would have links to other linux
  software maps, Donovan's editors page (or even mirror that page under
  dev-apps), various FreeOffice pages. The distrib group would have links
  to other distributions with comments on each, links to pages describing
  differences, packagers, linux standardization projects
  (http://paradigm.uor.edu/linux/standard/, the FHS page, etc), and to
  descriptions of different types of linux users out there. The install
  group would have links to hardware detection, pnp issues (is it really
  true that dos is inherently better for doing hardward detection? Why?),
  partitioning programs, the OpenBIOS project and similar things.

  There are pages about this sort of thing, right? One of the big
  problems with the linux community today is lack of coordination. The
  software and project maps have come a long way, but they only list major
  things that are looking for Linux publicity. Think of what you would
  need to read to become familiar enough with the topic to help out
  effectively for your dev group.

  At some point (soonish), I also want to pick out a member of each
  dev group that can be responsible for that dev group's section of the
  website. This is because seul-pub doesn't have enough manpower right
  now to handle the whole thing, and also because it would require having
  a seul-pub guy subscribed to all the dev groups trying to sort out what's
  useful, what should be changed, etc.  The volunteer from the dev group
  can work closely with seul-pub; he doesn't have to have HTML experience,
  so long as he can provide regular thorough reports and updates.

Anyway, I've gone on long enough. This is an enormous task, but we need to
do this so we can get organized enough to actually begin the project. We
need useful manpower, and we're not going to get it without informing people
about what we're trying to do. Information is power at this stage.

Thanks,
--Roger

===
SEUL-Leaders list, seul-leaders-request@seul.org
===