Difference between revisions of "Topic-by-topic Review"
|Line 59:||Line 59:|
Revision as of 09:56, 22 August 2012
This page describes the topic-by-topic review project for the elinux wiki.
This project consists of going through each major topic area on the wiki, and reviewing the content for accuracy and up-to-date-ness. Obsolete material will be moved to an "archive" section of the page (and dated, if possible). The latest areas of work in that topic will be added, and any appropriate page re-organizations will be made.
The idea is to overhaul the content over time, to make it better and more uniform, and especially to deprecate material that is obsolete or no longer relevant. Part of this concept is to do this one topic at a time, over a period of months and years, so that there can be focus in each area and visible progress as work is done.
Here are the major portals or topic areas on the wiki (independent of the hardware areas):
- Boot Time
- Memory Management
- Events (skip this one)
- Power Management
- System Size
- Hardware Hacking
- File Systems
- Real Time
- Resource Management
- Development Platforms (skip this one)
- Legal Issues
- build systems
- embedded distributions
- Android Portal
- Debugging Portal
It seems to me that this misses one major area of work, which is embedded distributions and build systems. These are both in the "toolbox" area, which may need to be broken out for individual sub-sweeps of it's own.
In order to do a methodical sweep of the site, there needs to be a mechanism to keep track of the status of a page (whether it has been reviewed, by whom, when it was last reviewed, what needs work on the page, etc.) Usually, the Discussion page for each page has meta-information like this about a page. Can we work out a way to automatically scan the discussion pages, and generate reports. This would be useful for finding pages that still need work.
It would be nice to have a quality metric, with objective criteria for when a page has reached some threshold of utility or quality, so that we can know when we're "done".
Another idea is to find experts to come in and help review material, on a one-time basis, for each topic area. Volunteer editors may not have the subject matter expertise to know how to edit an area. And it can take a very steep learning curve to come up to speed enough to contribute (even to know what material is now obsolete). We should determine a way of involving subject matter experts, such that they don't have to become wiki experts, and we minimize the impact on their time, at the same time leveraging their expertise.
- here's one: have volunteer editor send page (or page fragment) by e-mail to a subject matter expert, with specific
questions about the content (what is obsolete?, what is the status of this thing?, what is the next project in this area?)
- Problems: relies on volunteer editor knowing who the expert is, getting their e-mail address, and communicating with them.