Federico Mena,
thanks for your detailed input, much appreciated.
2009/10/22 Federico Mena
2009/10/22 Rupert Horstkötter
1. Use of Templates
This is perfect.
One of the things that templates would let us do is to give people an easy way to organize the wiki by themselves, rather than always relying on "official wiki editors" to do it. Let me throw around some ideas:
* Pages that refer to old versions of the distro; we can group them in a consistent way. Maybe we can have a little template that says "See instructions for [11.2] [11.1] [10.3]", etc.
Aligned. I'd also propose a wiki-template "tested with openSUSE 11.0, 11.1, 11.2" on top of topics that apply to several versions of openSUSE. That way, we can guarantee to the user that a certain howto works with the flagged version of openSUSE.
* Pages that refer to the same general topic but are not under a "topic/" hierarchy or otherwise in an easy-to-access group. We can provide guidelines on how to group them, create a topic template for them, etc. Topic templates could probably have common things like:
- Link to the topic's toplevel - Link to the OBS project - Link to important documentation on the topic - Link to starting points - Link to bugs
Some of our bigger subprojects already have these (KDE, GNOME), but other large chunks of the wiki could use similar templates very well.
Good idea! May you provide an example template from one of our bigger subprojects here?
2. QA Process I appreciate to see a lively discussion about the proposed QA process (the central part of my proposal) and I clearly see your concern from a maintenance perspective. cboltz proposed to utilize the MediaWiki Extension FlaggedRevs instead of the Sandbox/new-wiki approach.
FlaggedRevs sounds much better than sandboxing; the latter could lead to bureaucracy and pages which remain stuck in the sandbox even though they are in a good shape.
While the majority of interested parties seems to be on the same page here, I'm not completely sure if the sandboxing approach leads to that much overhead and is to be neglected in favor of the FlaggedRevs approach. JFYI, I interviewed Martin Gräßlin from ubuntuusers.de last Friday on IRC about the sandboxing approach (to get experiences - they use something similar for their ubuntuusers.de wiki) and he reported very good experiences with this approach from a QA perspective - and an acceptable amount of maintenance time. Btw, Martin Gräßlin has written a comparison of Wikipedia and the ubuntuusers.de wiki some days ago at his blog (unfortunately in german, but Google translate may help here) http://blog.martin-graesslin.com/blog/2009/10/wikipedia-im-vergleich-zum-ubu... That said, if the majority of interested parties is in favor of the FlaggedRevs approach I'll certainly go along with that decision, no question. Just some thoughts: I proposed the sandboxing as it definitely guarantees an end of the uncontrolled wiki-growth we currently have to face. Furthermore, with the proposed proof-reading/reviewing process with a dediated wiki-forum in combination with sandboxing we can make use of currently 35.000 proof-readers which hopefully leads to better QA and last but not least, I cannot really see the disadvantage of "discouraging contribution" I heard several times when implementing sandboxing. I mean, we just limit the contribution (and for major edits) to the Sandbox - it's just a matter of how to deal with new articles (and major edits) initially. We don't discourage people to write articles that way. Just my 2c! What do you think about it?
I was reading this: http://en.wikipedia.org/wiki/Wikipedia:Editorial_oversight_and_control
And it pointed me to "WikiProjects", which is a very valuable part of Wikipedia: http://en.wikipedia.org/wiki/Wikipedia:WikiProject
A WikiProject is basically a group of editors who have a common interest in one topic (botany, musical instruments, etc.) and who commit themselves to improving all the pages related to that topic. I really like their explanation of what a WikiProject is from here: http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Council/Guide
There are all sorts of ways to encourage knowledge-building and collaboration. See for example this page:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Percussion
Definitely a good idea from a long term perspective. We just need way more committed contributors to the wiki to be able to implement such Wiki-Projects. Let's keep this in mind and come back to this idea once we have the big showstoppers ironed out.
They have a "Collaboration of the Month", where everyone participates to take one important article and make it excellent:
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Percussion/Collaboration_...
That's something I really like. I had a rather similar idea when riting my concept-proposal: What about announcing a monthly "focus on <insert-topic-here>" to the broader openSUSE community (utilizing planetsuse and/or the forums)? Like a call for participation to the community to help improving a certain topic-area of the wiki. Something along the lines: "In October we'd like to focus on PIM and IM and we encourage everyone interested to test-out article-instructions within that topic-area with various versions of openSUSE and ensure the instructions are (still) valid and easily understandable." The result would be QA and improvement of existing ariticles. Next month we may focus on "Software Management" and so on. For supporting purposes of community engagement, some Wiki team members could sign responsible to support the efforts via IRC - just an idea.
For openSUSE, we could similarly encourage volunteers to maintain sections of the wiki based on related topics.
Wikipedia has "featured articles": when you go to the main page, you get a snippet from an article that has been decided to be really good. This may be a good way to do two things for us: first, to promote really good articles, and second, to let people know about parts of the openSUSE organization or technical aspects that they didn't know before.
Excellent idea! +1
3. Wiki-Frontpage aka Portal
This is perfect.
4. Guidelines Robert outlined that the Guidelines should be easily understandable in 5-10 minutes and I totally support this point of view. We shouldn't scare away potential contributors but encourage them to participate.
Have you seen this? http://en.wikipedia.org/wiki/Wikipedia:Be_bold
It's a very nice thing to keep in mind for potential contributors :)
Also, for people who don't quite know how to get started with the structure of a page, our own OpenSUSE_Style_Guide page could borrow some ideas from http://en.wikipedia.org/wiki/Wikipedia:Layout
We could probably the MediaWiki:Sitenotice special page. This is the little area that can be made to appear automatically at the top of all wiki pages. We could have "cleanup weeks" every now and then, where the Sitenotice points people to guidelines about how to clean up pages, group related ones, etc.
Very valuable input, thanks. I guess the creation of Guidelines and their proper promoting (I like the Sidenotice idea) is anyway an area where we still have to do lots of brainstorming.
(By the way, the people in freenode's #wikipedia are very helpful. We could certainly get some good tips from them.)
So, next question is: how to proceed now?
I'm very excited about the possibility of those WikiProject-like things. It reminds me of when the GNOME team had a period during which we organized the GNOME pages really well; it was very productive. I can only imagine that it would be just as good for other teams.
An overview about timezones our team members live in would be great here - I'm in CEST timezone.
UTC -7 here.
Thanks for coordinating all of this, Rupert :)
Federico
-- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter@opensuse.org Jabber: ruperthorstkoetter@googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org