On 3/12/07, Nick Matteo <[EMAIL PROTECTED]> wrote:
> > Step 3) Identify content categories.
> > 16 Users pages (some deleted by Nick)
>
> Really? I hadn't thought so.
Maybe you didn't delete any. I'm not sure. There were some
user pages that basically said, "Hi, I'm a user," and nothing more.
> > 3 ??? (I cannot tell what these 3 pages are.)
>
> I am curious which pages you mean.
According to my notes, I could note categorize the following pages:
Afterboot
Gobo
Package Bundles
You may have already deleted them. I did not check.
> > Step 4) Match content categories with user groups.
> >
> > Step 5) Impose category framework
> > Trash (was 37, currently ?)
> > |
> > +--> Spam (was 7, currently ?)
>
> Surely we can delete these rather than categorize them. ;-)
One of my proposed policies will be that pages go into the
Trash category for 30 days before they are actually deleted. As for
spam pages, maybe we can delete them immediately, but I'm really
hoping we can prevent spam pages from ever being created.
> > Step 6) Write and enforce WikiTeam policy guidlines.
> >
> > Step 7) Implement maintenence tracking techniques
> > Each page in the wiki will link to the appropriate "Last_Reviewed_..."
> > page.
> >
> > For example:
> >
> > This page [[Last Reviewed March 2007]] by mpb.
> >[...]
> > Create a Todo page. Any page that needs work done should link to the
> > Todo page. This will make it easy (again via back-links) to see how
> > many pages across the whole Wiki need work done.
>
> I would use templates rather than links here. E.G.
> {{lastreviewed|3|12|2007|mpb}}; or with a bit of black magic, just
> adding {{lastreviewed}} when you do it. The template could take care
> of categorizing, etc, and imo would be less of a hassle than getting
> backlinks from a page each time. Same for {{todo}}.
>
> Plus, this could let us decide which user groups see the review
> message, maybe show the number of edits since review, etc. without
> editing all the pages.
If a template belongs to a category, does adding the template
to a page add the page to the category, too? I was uncertain about
this.
Regarding {{lastreviewed}} without a date, how do I tell, six
months from now when the page was last reviewed? And after I review
it (again), how would I update the pages to show that I had just re-reviewed
the pages. Pages (at least the core documentation) should be reviewed
around every 3 months, I think.
I'm all for using MediaWiki's bells and whistles (like
templates) where appropriate. I didn't know you could do templates
with parameters.
--------
On 3/12/07, Carlo Calica <[EMAIL PROTECTED]> wrote:
> > Step 2) Define the goal of the Wiki.
> >
> > As I see it, the goal of the Wiki is to:
> >
> > a) help potential users efficiently decide whether or not to install
> > Gobo
> >
> > b) help begining users efficiently become advanced users
> >
> > c) help advanced users improve Gobo (via bug reports and recipe
> > submissions) and customize Gobo to their specific needs
> >
> > d) allow the devel team to focus on development rather than support,
> > and serve as a reference for how things should work
> >
> > Some of these goals overlap with the web site, which is why I am
> > interested in creating a consistent user experience across the two of
> > them.
> >
>
> I completely agree with a+b. c is outside the scope of a wiki.
c is important. The Wiki needs to tell advanced users how to
submit bug reports and how to submit recipes and possibly also how to
submit packages. Right now, none of these is documented clearly in a
single place. The Wiki doesn't have to do these functions, it merely
has to tell advancesd users where and how to do them.
> > Step 3) Identify content categories.
> >
> > As I see it, the content categories, ordered from most pages to least
> > are:
> >
> > Pages Category
> > 97 Reference pages
> > 45 Handbook pages
> > 37 Trash pages (many already deleted by Nick)
> > 25 Howtos
> > 22 Discussions
> > 16 Users pages (some deleted by Nick)
> > 15 Community pages
> > 8 Archive pages (of historic interest)
> > 7 Spam pages (possibly now deleted by Nick)
> > 6 "WikiTeam pages" that discuss wiki policies, goals
> > 5 "About Gobo" pages
> > 5 Platform specific pages
> > 5 Redirect pages
> > 3 ??? (I cannot tell what these 3 pages are.)
> > 2 Floater pages that need to be merged with the pages they support
> Way too many categories. For instance. Handbook and Howto could
> probably be merged.
Handbook and Howto will both be subcategories of the
Documentation category.
The Handbook tells the begining user everything they need to
know to get comfortable using Gobo. Every user will need to know 80+%
of what is in the handbook. The Handbook needs to function as a
cohesive whole.
Howtos are different - each describes how to perform a single
specilized task. For example, how to get Asterisk and Zaptel
running. Only a small percentage of users will use any given Howto.
Each Howto will be pretty much self contained and independant of
everything else.
> What are Community pages?
Pages that talk about the community. Various roadmaps for
future development. Various "blog" like pages of people describing
their impressions of using Gobo. Definitions of the roles of various
developers. Information about the mailing lists. A pointer to the
CVS access at savannah.nongnu.org. Brainstorming pages. This is all
stuff that is already in the Wiki.
> The actually categories can remain somewhat fluid during the rework.
Of course.
> You've done a great job analyzing the current state and outlining a
> way forward. thanks. Based on the feedback of this thread you
> should develop step 6 (the wiki guidelines) further. Then post to
> the user list for additional comments and recruit volunteers.
The guidelines definitely need to be written before any
content-editing volunteers are recruited. However, I may do the
categorization, and some reworking of the entry pages and table of
contents pages before writing the guidelines. Various techniques
(back-linking and templates) need to be tested in practice before
volunteers are recruited and trained. (Much easier to train volunteers
once than to try to retrain them.) And I think I need some actual
experience editing the Wiki a bit before I write a first draft of the wiki
guidelines.
Thanks to everyone for all the suggestions.
-mpb
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
