Difference between revisions of "Topic-by-topic Review"

From eLinux.org
Jump to: navigation, search
(Created page with "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 fo...")
 
Line 32: Line 32:
 
* Legal Issues
 
* Legal Issues
 
* Toolbox
 
* Toolbox
 +
** build systems
 +
** embedded distributions
 
* Android Portal
 
* Android Portal
 
* Debugging Portal
 
* Debugging Portal
 
* Category:Categories
 
* Category:Categories
  
It seems to me that this misses one major area of work, which is embedded distributions and build systems.
+
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.
 +
 
 +
== Issues ==
 +
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".
 +
 
 +
== Finding experts ==
 +
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.
 +
 
 +
Ideas?

Revision as of 09:54, 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.

Topic List

Here are the major portals or topic areas on the wiki (independent of the hardware areas):

  • Boot Time
  • Memory Management
  • Security
  • Events (skip this one)
  • Multimedia
  • Power Management
  • System Size
  • Hardware Hacking
  • File Systems
  • Real Time
  • Resource Management
  • Development Platforms (skip this one)
  • Networking
  • Firmware
  • Legal Issues
  • Toolbox
    • build systems
    • embedded distributions
  • Android Portal
  • Debugging Portal
  • Category:Categories

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.

Issues

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".

Finding experts

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.

Ideas?