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...")
 
 
(6 intermediate revisions by 2 users not shown)
Line 16: Line 16:
 
Here are the major portals or topic areas on the wiki (independent of the hardware
 
Here are the major portals or topic areas on the wiki (independent of the hardware
 
areas):
 
areas):
 +
* Embedded Linux Glossary - definitions of general terms
 
* Boot Time
 
* Boot Time
 
* Memory Management
 
* Memory Management
Line 32: Line 33:
 
* 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?
 +
* 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.
 +
** Possible Solutions: Ask on the Embedded Linux mailing lists. Solicit input from community on IRC.
 +
** Maybe we should keep the list of experts on the Discussion page for each portal?  (Maybe this policy could apply to all
 +
pages???)
 +
 
 +
== Sequence ==
 +
This is the sequence of operations for cleaning up a topic area:
 +
 
 +
Building a proper checklist is a work-in-progress...
 +
 
 +
* First, create the glossary
 +
** Make sure that definitions related to a topic area are available on a glossary page for that area
 +
* Check the portal page
 +
** check index for related pages (search for terms on the glossary page, to find pages related to this topic)
 +
** make sure all linked pages are categorized
 +
** check the topic category to find pages that are not linked in
 +
* Check individual pages
 +
** is the material obsolete (if so, move to a history section)
 +
** are any major new features or technology areas missing (if so, at least put stubs for them)
 +
* Check for external/new material:
 +
** Check for LWN.net articles on the given topic
 +
** Check for stackoverflow articles
 +
** Scan presentations for unlinked articles
 +
* check for stubs, and replace with content
 +
** This may require research or discussion with experts

Latest revision as of 09:13, 30 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):

  • Embedded Linux Glossary - definitions of general terms
  • 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?

  • 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.
    • Possible Solutions: Ask on the Embedded Linux mailing lists. Solicit input from community on IRC.
    • Maybe we should keep the list of experts on the Discussion page for each portal? (Maybe this policy could apply to all

pages???)

Sequence

This is the sequence of operations for cleaning up a topic area:

Building a proper checklist is a work-in-progress...

  • First, create the glossary
    • Make sure that definitions related to a topic area are available on a glossary page for that area
  • Check the portal page
    • check index for related pages (search for terms on the glossary page, to find pages related to this topic)
    • make sure all linked pages are categorized
    • check the topic category to find pages that are not linked in
  • Check individual pages
    • is the material obsolete (if so, move to a history section)
    • are any major new features or technology areas missing (if so, at least put stubs for them)
  • Check for external/new material:
    • Check for LWN.net articles on the given topic
    • Check for stackoverflow articles
    • Scan presentations for unlinked articles
  • check for stubs, and replace with content
    • This may require research or discussion with experts