November 2009 - openSUSE Wiki - openSUSE Mailing Lists

[opensuse-wiki] FlaggedRevs experiment
by Rajko M. 13 Nov '09

13 Nov '09

> Now I'm removing last traces of extension and I'll try installation again. Some of tables that I have to remove are called reader feedback. That is the latest feature in FlaggedRevs extension. And in the meantime, cleanup process revealed some missing colums in page table, which can mean improper installation. -- Regards, Rajko openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

3 9

[opensuse-wiki] openSUSE Wiki
by Nedin Ametovski 12 Nov '09

12 Nov '09

Hello, I like to participate for translating openSUSE wiki on my language (macedonian), also i`m proud user on openSUSE,and i like to promote Suse here in Macedonia. Cant you tell me is that posible and if it is how to procced further. Best Regars, Nedin Ametovski -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

[opensuse-wiki] QA process - FlaggedRevs VS Sandboxing
by Rupert Horstkötter 09 Nov '09

09 Nov '09

Team, we still need to agree on either Sandboxing or FlaggedRevs as our QA process for the openSUSE Wiki - I'm the assignee to start this discussion... so, here it is. During our Meeting last Friday, the general concensus was to go for the Sandboxing approach, but I know that there are other opinions as well from parties not joining the Meeting and thus I'd like to give another possibility to discuss the Pros and Cons of both Approaches before we decide which one to implement finally. During our meeting last Friday, we came up with the proposal to get the opportunity to test both approaches in a testing environment to give the Wiki Team an actual idea. Frank, would it be possible to set this up? This isn't urgently needed but would certainly be desired. So far the foreword :-) As I outlined several times before, I myself am for Sandboxing (I mean this was an integral part of my initial concept-proposal) as our QA Process. I'll explain it again: 1. New articles would need to be created in a Namespace Sandbox, so e.g. Sandbox:Nvidia. As soon as the author feels the article confirm with the Guidelines and sufficient from a content perspective, he'd present the new article in Sandbox for reviewing purposes. This would be done utilizing a (to be created) Wiki Forum at forums.o.o where we may use a crowd of 35.000 proofreaders (at best). The author gets feedback that way and the article should evolve. After a certain time, the new article will be moved and categorized into the main Namespace and thus be part of approved openSUSE documentation. The decision to move the article would be the responsibility of a Wiki Moderator. Thus I proposed to define the role of a Wiki Team Member as a supporter/moderator (this also makes sense for e.g. the mentoring program we'd like to implement - different story) 2. Existing content? We need to distinguish between minor and major edits here and define those within the Guidelines. A minor edit covers spelling corrections, add a link as a reference etc. Within the Guidelines we encourge editors to do only minor edits to existing pages. Whenever a major edit needs to be done/is desired, the author requests a working copy of the article in Sandbox where he can work on it. Once it's done, the new article needs to pass the reviewing process, just like a completely new one, and the decison IF that article is finally sufficient to replace the existing one in main Namespace is the sole courtesy of the Wiki Team. We certainly may need to restrict this approach to the main Namespace (content interesting for the end user), but the decision about the structure of the Wiki is ongoing - started by Henne. Thus we need to look how that works out in the end (and restrict the Sandboxing approach just to parts of the Wiki structure we'll agree on). Yeah, that's it! I feel this as a valid approach to stop the uncontrolled growth of the openSUSE Wiki and to ensure proper quality of articles confirm with the Guidelines from a design, formulation and conception perspective. To get feedback about this approach I interviewed Martin Gräßlin from wiki.ubuntuusers.de - they have imho one of the best wikis out there from a usability and quality perspective and they use this approach for ages. Martin told me that the acceptance factor is awesome and the process is easy to handle for the Wiki Team. That's what I can tell you, i.e. forward to you as an actual experience. The alternative would be to go for the FlaggedRevs MediaWiki Extension proposed by cboltz and afaik supported by Rajko_m. FlaggedRevs, in short, provides the opportunity to have several revisions of articles in parallel and the one approved by the Wiki Team is shown to the user, the others are hidden until one of them gets approval and replaces the currently shown one - at least that's how I myself understood this approach. The Cons from my perspective are the additional maintenance of a MediaWiki Extension that has writable access to the database (according to Frank). Also I do not see how we should utilize a Wiki-Forum then (at least not obviously) and I myself feel no real advantage over the Sandboxing. That said, the intention is to give this discussion another period to evolve, so please, FlaggedRevs supporterrs, jump in and explain. Finally I'd like to close this discussion with an ultimate decision about the QA process we're going to implement - at some point in time we need to go forward and we need an agreement for either approach to cover/explain it within the Guidelines. Just now, the tendency by the team is to go for Sandboxing (checked in the Meeting - see transcript http://en.opensuse.org/Wiki_Team/Meetings/2009_10_30-transcript) but I'll certainly go along with whatever decision made by the team - I'd just like to have a decision. I'd propose to discuss this for a timeframe of one week as of now and afterwards we vote - sounds sufficient? Thanks, R -- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter(a)opensuse.org Jabber: ruperthorstkoetter(a)googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

4 6

[opensuse-wiki] Feedback wanted
by Jon Rocker 09 Nov '09

09 Nov '09

I posted a thread on the openSUSE Forums. We have received some feedback there. The feedback needs to continue, so that we can make this the best wiki and portal possible. Here is the link to the thread on the openSUSE Forums: http://forums.opensuse.org/general-chit-chat/424752-sneek-peak-new-opensuse… -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

3 2

[opensuse-wiki] Export functionality in openSUSE wiki
by Rajko M. 07 Nov '09

07 Nov '09

In thread [opensuse-wiki] QA process - FlaggedRevs VS Sandboxing I mentioned problem to export page with whole history. The problem is that server http://en.opensuse.org that errors out with 504 if I ask for complete article with history. If request is for export of current revision then all is good. I didn't attempt to debug problem, but CBoltz has more experience with this. -- Regards, Rajko openSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

1 0

[opensuse-wiki] Sandbox implementation
by John E. Perry 07 Nov '09

07 Nov '09

One of the beauties of a wiki is that much more information can be put into it because anyone can put information into it. That said, if it's done without care and some control, we find a mess after a short time. So we need to try to keep the principle of letting everyone contribute with little or no restriction but restrict people's ability to put stuff in. :-) I like the sandbox idea; but putting limits on its availability to the open public, either as contributors or as users, violates the original wiki principle. How about a parallel-tree implementation? There would be two trees, one rooted as "sandbox" and one as "certified", or some such. Every new contribution is flagged as "sandbox" and linked into the sandbox tree, but also linked appropriately by the contributor and/or editors into the category and/or project trees. Users would normally search on verified, conformant resources in the "certified" tree, but would have the clearly marked option of searching on unverified, tentative sandbox resources, too. Browsing indexes would contain all contributions, but the sandbox stuff would be highlighted, and maybe even turned on/off at the user's option. Access to the sandbox tree would be for editors and moderators, and all new contributions would be forced into the sandbox tree. As moderators, negotiating with editors and contributors, approve contributions, the "sandbox" link would be removed, leaving the contribution clean and already in its proper place in the wiki, and now available to the default search and unmarked as tentative or developmental or whatever. There would have to be a parallel sandbox portal, too, so editors wouldn't have to search through the entire wiki for the prospective contributions they want to work with. This parallel tree would mirror the certified tree, to make it easy for editors and moderators to see how it would fit into the certified wiki. Things to discuss would be how easy to make sandbox material available to normal users, how to ease discussions between team members and contributors, who gets to remove the sandbox flag, whether and how to distinguish "major" from "minor" edits, and likely other matters that don't come to my mind at the moment. And, of course, the first discussion would have to be whether this is even worth discussing in detail. I don't believe this proposal is premature, since implementation methods could influence opinions on the merits of FlaggedRevs vs. sandbox ideas, and indeed I believe I perceive a melding of the two concepts here. John Perry -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

4 4

Re: [opensuse-wiki] Wiki Team Meeting 091030 - Meeting Minutes
by Rupert Horstkötter 06 Nov '09

06 Nov '09

Shayon, 2009/11/5 Shayon <hkwarlock(a)gmail.com>: > Rupert Horstkötter wrote: >> Team, >> >> #3 – Frontpage/Portal (Assignee: rhorstkoetter, Shayon) >> We'd like to replace the current http://en.opensuse.org with a Portal >> to openSUSE documentation resources (the wiki) while offloading >> content from the current http://en.opensuse.org to >> http://www.opensuse.org – a two-column layout is desirable. >> Jbrockmeier requested to leave the sponsor links and move them to the >> right column if possible - rhorstkoetter will sync this with the >> webteam. Shayon is responsible for the development of >> http://en.opensuse.org/Portal_New, Rajko's contribution would be >> desirable here. We need to focus on proper categorization (provide as >> less categories at the main Portal as possible for usability purposes) >> while utilizing wiki-portals/projects for deeper hierarchies – see #4. >> Once this is done, the draft for the main Portal should be pushed to >> the marketing- and webteams for smooting out the design, language and >> overall appearence of the Portal. The guidelines will be prominently >> placed at the main portal. Finally we'd like to have an openSUSE-like >> http://tinyurl.com/y8gh6hj - just to get a general idea. >> >> >> Thanks, >> Rupert >> > > hello, > While i was planning the layout of the frontpage and sorting the things > out.I felt that,lets not make the whole thing portal oriented.And change > a bit of things which are not related with the above matter.Rather i am > trying to sort the important categories which would be helpful for the > frontpage to guide the end-users in a desired manner.And also i am > leaving a space for the Guidelines to be added as to make it easier for > the future purpose.And i'll make the layout in such a way that > everything is taken care of.I hope everything is satisfying. (this just > the bit).After i complete the layout of the frontpage -i'll let you know! :0 > Looking forward to it - thanks for your engagement! Best, R > If you have got anything to say/comment about it .Let me know. :) > > Best, > Shayon > > -- > openSUSE Wiki Team Member > http://en.opensuse.org/User:Wwarlock > Website: http://www.shay0n.hpage.com > Email: hkwarlock(a)gmail.com > Twitter: wwarl0ck > > -- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter(a)opensuse.org Jabber: ruperthorstkoetter(a)googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

[opensuse-wiki] openSUSE wiki Portals
by Petr Uzel 05 Nov '09

05 Nov '09

Hello, One of the topics we discussed at the IRC meeting on Friday was Wikipedia-like Portals. Here I'd like to summarize how we could make use of it and what steps are needed. Overview ======== Henne Vogelsang came up [1] with the idea of adopting Portals from Wikipedia to openSUSE wiki. The main goal of portals is to nicely present related stuff and give overview about one topic, which means something like an entry page to one part of the wiki. I can imagine e.g. KDE, GNOME, YaST, OBS, Developers, Packaging, Education, Medical and other Portals. Wikipedia uses prepared skeletons and templates which makes creating of new portals quite easy, especially with help of some guidelines [2,3]. Some examples of Wikipedia's portals: [4,5] How are the Portals created =========================== Let's take a look how new Portals are created in Wikipedia. You start by creating new page into which you 'substitute' predefined skeleton [7], which defines several sections that will appear on the Portal page. Portals on Wikipedia consist of several sections. Different portals use different layouts and sections. Here's the list of common sections used in Wikipedia: - Browserbar - navigation bar with links to top-level portals - Intro - some introduction to the portal, what is it about - Selected article - Did you know? - list of some short facts - Picture of the month - Categories - WikiProject - Things to do - Topics - Index of articles - Related portals - News - .... Some of the sections are same for all portals, like Browserbar or Selected article (which, if I understand correctly, use some magic to select random article belonging to the topic). These are implemented using templates. We should think about which sections would be useful in our wiki. Other sections, like Topics or Related portals are unique across the portals, which means they are created manually for each portal. The templates Wikipedia uses for creating portals require ParserFunctions extension [6], which in turn requires MediaWiki 1.7.0 or above. Currently, our wiki runs on MediaWiki 1.5.8, so it seems it is not possible to deploy that before upgrade to new MediaWiki is done (which, if I'm not mistaken, should happen soon after 11.2). On the other hand, we will not probably need all the templates Wikipedia uses, so there's a chance that the ParserFunctions extensions won't be necessary. What to do ========== Here are the tasks we need to do if we decide to adopt the Portals to openSUSE wiki: 1) Identify which sections/templates would be useful in openSUSE wiki --------------------------------------------------------------------- Let's go through some Wikipedia portals and think about the sections they use. I don't think we need 'Did you know?', 'Selected article' or 'Picture of the month' sections. On the other hand, there might be other sections useful for our wiki, like 'List of Howtos' or 'Application of the month'. 2) Design how default openSUSE Portal should look like ------------------------------------------------------ Which sections should the default Portal contain and what should be the layout? Since the Portals can be customized, this does not mean designing universal portal layout, just something from which it is easy to start with new portal. 3) Port needed templates from Wikipedia --------------------------------------- The big question here is what wiki instance should we use for development. I see three options: - setup testing wiki instance with ParserFunctions extension somewhere - wait until openSUSE wiki is upgraded - try how that would work with current wiki (that would answer the question whether ParserFunctions extension is actually needed :) ). 4) Adopt Portal creation guidelines from Wikipedia -------------------------------------------------- This one should be easy :) So, what do you think? Does this all make sense? What did I miss? [1] http://lists.opensuse.org/opensuse-boosters/2009-10/msg00004.html [2] http://en.wikipedia.org/wiki/Wikipedia:Portal/Guidelines [3] http://en.wikipedia.org/wiki/Wikipedia:Portal/Instructions [4] http://en.wikipedia.org/wiki/Portal:Linux [5] http://en.wikipedia.org/wiki/Portal:Mathematics [6] http://www.mediawiki.org/wiki/Extension:ParserFunctions [7] http://en.wikipedia.org/wiki/Template:Box_portal_skeleton -- Best regards / s pozdravem Petr Uzel, openSUSE Boosters Team ----------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel(a)suse.cz Lihovarská 1060/12 http://www.suse.cz 190 00 Prague 9, CR

4 11

Fwd: [opensuse-wiki] Use of namespaces in openSUSE wiki
by Rupert Horstkötter 05 Nov '09

05 Nov '09

Forward, accidentally responded to Henne alone. ---------- Forwarded message ---------- From: Rupert Horstkötter <rhorstkoetter(a)opensuse.org> Date: 2009/11/5 Subject: Re: [opensuse-wiki] Use of namespaces in openSUSE wiki To: Henne Vogelsang <hvogel(a)opensuse.org> Henne, 2009/11/5 Henne Vogelsang <hvogel(a)opensuse.org>: > Hi, > > Rupert Horstkötter wrote: > >> The SDB will anyway be moved out of the wiki and will be maintained >> external. > > Says who? Why would anyone do that? I think it's more than stupid. The > place for user contributed content is our wiki. Nearly every user > contributed content is in the form of howtos, problem solutions, small > documentation pieces (stuff that belongs to the SDB). Why would you > separate that from the wiki? > As I said, I just have semi-verified information here - I'm sorry. To my knowledge, open-slx.com, the company producing and supporting the openSUSE Box Product as of 11.2 will take over the SDB, maintain it and feed it with support information. Please trigger Klaas to get more detailed information about it. He should be able to tell you what's planned in particular. Thanks, R > Henne > > -- > Henne Vogelsang, openSUSE. > Everybody has a plan, until they get hit. > - Mike Tyson > -- > To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org > For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org > > -- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter(a)opensuse.org Jabber: ruperthorstkoetter(a)googlemail.com -- Rupert Horstkötter openSUSE Community Assistant http://en.opensuse.org/User:Rhorstkoetter Email: rhorstkoetter(a)opensuse.org Jabber: ruperthorstkoetter(a)googlemail.com -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

2 1

[opensuse-wiki] Use of namespaces in openSUSE wiki
by Rajko M. 05 Nov '09

05 Nov '09

Primary question is, should we move articles like "OpenSUSE mailing list netiquette" to more appropriate place like namespace [1] OpenSUSE: with new title "OpenSUSE:Mailing list netiquette" and with current article left as redirect to new location, as netiquette is linked from many places? When we talk about cleaning wiki, anything that is meta/community information about openSUSE should use existing namespace openSUSE, not the Main one as it is now. I would also propose creation of new namespaces like Development, Portal, News, Sandbox, etc. with links to entry pages in Main namespace, or only entry pages in Main namespace. With this we will have clean Main namespace for user searching certain topics and ability to use wiki for more then a few documents targeted to ordinary visitors looking for help. Few indexes in Main namespace will provide links to other namespaces and keywords for search engine. [1] What is namespace and how to use it? http://meta.wikimedia.org/wiki/Help:Namespace and particularly section "Namespace uses" -- Regards, Rajko OpenSUSE Wiki Team: http://en.opensuse.org/Wiki_Team People of openSUSE: http://en.opensuse.org/People_of_openSUSE/About -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-wiki+help(a)opensuse.org

5 8