Wiki Editing Guidelines

Ole Tange at
Wed Feb 21 12:50:17 CET 2007

On 2/20/07, Harald Welte <laforge at> wrote:
> On Tue, Feb 20, 2007 at 01:58:38PM +0000, Ole Tange wrote:
> > On 2/19/07, Harald Welte <laforge at> wrote:
> >
> > >>From reviewing the 'Recent Changes', I have drafted a (currently still)
> > >small list of rules for Wiki editing.  It is available at
> > >
> >
> > I like most of the guidelines.
> >
> > I am not too happy about the Wishlist part, though. Putting "wishlist"
> > in the title will imply that an idea can only have 2 states: Being on
> > the wishlist or not. And that is not the case.
> >
> > It is a continuum where an idea progresses from being just a wild idea
> > to being a rock solid application.
> I agree with you.
> However, I would really like to see anything non-factual (or, let's say,
> anything that is not on our 'official roadmap') to be clearly marked, if
> not better in some specific section of the wiki only.  Or maybe in a
> different wiki alltogether(!).  Please don't get me wrong, I appreciate
> the creativity of all those suggestions.  But we cannot have more
> suggestions/dreams/plans in the wiki than actual, "factual content". I
> we run into that case, the wiki simply becomes irrelevant to people who
> want to actually practically learn something about OpenMoko and/or the
> supported devices.

I understand your concern, but again: A specification may be factual
content - even if there is no implementation.

Would it work if we could mark the pages that describe concepts that
have working code?

I am thinking if it is possible to have MediaWiki put in a warning
flag in the first heading that the concept on this page does not have
working code. This warning should only be displayed if the page does
not have the [[category:working code]].

In any case I would prefer marking the pages that have working code
rather than those that have not. The reason being the pages that have
working code are most likely maintained by people who know what they
are doing, where as new pages may be created by someone who does not
know of this guideline.


More information about the community mailing list