[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Leaders: -dev website sections
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
email@example.com with cc to firstname.lastname@example.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.
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.
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.
SEUL-Leaders list, email@example.com