Gentoo Wiki:Meetings/2010-05-10

Meeting Time

• 2010-05-10 20:00 UTC
• #gentoo-wiki on freenode

Participants

• hwoarang (developer, moderator)
• a3li (developer, now project lead)
• Mousee
• fekepp
• quantumsummers
• idl0r
• ali_bush
• opcode0x90
• willikins
• ni1s_eee
• amoskvin
• Monkeh
• yporti
• spatz (developer)
• darkside_ (infra guy)
• Poly-C_atwork
• dansan
• rafaelmartins
• crimer
• slep
• lk4d4

Agenda

none

Logs

• log

Summary

(The questions and answers are just grouped)

<hwoarang> infra services

• <hwoarang> robbat2 (infra guy) asked, what we need.
  • <hwoarang> work on a3li wiki page and then sent the configs file to robbat
  • <darkside_> use a git repo with configuration files

<a3li> mission statement

• <Mousee> we've a "draft mission statement"
• <hwoarang> the mission plan is to host an official wiki on our infra machine
• <hwoarang> wiki could be a nice place for devs+users to cooperate
• <hwoarang> using bugs+cvs for docs like we do now is not an option

<a3li> content

<quantumsummers> draft for guide-xml

• <quantumsummers> would like to think of this as a collab space for docs in progress
  • <quantumsummers> then the wiki doc gets guildexml-ified
    • <hwoarang> quantumsummers: that was a huge conversion on month ago
    • <hwoarang> if we need to write everything on guide-xml
      • <quantumsummers> I would be happy to assist with writing the converter using mwlib
      • <spatz> there's no intention to convert everything to guidexml, the wiki is supposed to be separate from official documentation
      • <spatz> both, just look at the content of g-w.com. not everything should be official documentation, and there's no way it can be maintained properly as official documentation

<quantumsummers> event planning

• <quantumsummers> there is an events plugin, so meeting planning
  • <quantumsummers> calendar in general, conferences

<fekepp> needed categories

• <quantumsummers> we could base it off of the existing doc structure http://www.gentoo.org/doc/en/
• <quantumsummers> perhaps off of system profiles
• <a3li> we basically can do one level of proper subclassing with namespaces
• <fekepp> as a wiki evolves also the structure evolves, but a wise choosen structure at the start which can be extended later could be useful
• <fekepp> beside categories there are indexes too
• <quantumsummers> we could have system, desktop, server, multimedia, security, hardware portals
  • <ni1s_eee> yes, I would rather have that than ToC templates
  • <quantumsummers> perhaps system, should be toolchain && system set
  • <quantumsummers> that can be further dissected for hardened & non-hardened
  • <Mousee> How are specific architectures handled then, in such a portal layout?
    • <quantumsummers> each portal has outlines for the arches
  • <quantumsummers> profiles still seem to me a good way of organizing thing as well
  • <ni1s_eee> another idea is to have them per purpose or endeavour, i.e system, web server, spam bot, etc.
    • <quantumsummers> seems too large a set, to use a per-endeavor schema
    • <quantumsummers> the various projects could have portals, yes. or we have a portal for all projects, which are then represented in outlines
    • <ni1s_eee> perhaps, i suspect there's going to be overlaps all over the place regardless of the portal 'mode'
      • <Mousee> quantumsummers: the later idea sounds more "user friendly", in terms of navigation, at least
  • <winterheart> Portals is maybe some replacement for existing projects on g.org

<amoskvin> multiple package versions

• <amoskvin> as in, when would information for old packages be cleaned off?
  • <hwoarang> i guess this is up to the editor to keep it up to date
  • <a3li> when the packages are no longer in the tree
    • <ni1s_eee> on g-w.com its often killed when it leaves the tree and diffrent version are talked bout under diffrent headings
    • <hwoarang> I wonder if we should delete the articles or just mark them as "old" "depcreated" or what. some ppl might have very old systems
      • <Mousee> We could always duplicate a page and throw it into an "archive" of sorts. You'd still have to create a policy on when to flush the archives out though. It'd add a bit of extra work.
      • <a3li> there's the revision history. people needing old info can see old revisions
        • <fekepp> a3li: if there is a change for old versions you are not able to edit the historic version. i would suggest to write some hints at the end of an article if there are only small differences, or use an own wiki page only for the old version if there are big differences. in that case it must be explicited marked as old and maybe linked to the new version article. something like unmaintained of course possible too
        • <a3li> fekepp: true, but old stuff shouldn't change. if it is old enough to be no longer included in the latest revision, there should be nothing to change.
        • <fekepp> yes of course, i would suggest to keep only text about in-tree-versions
      • <ni1s_eee> a page with with really old stuff could just have a warning at top
      • <amoskvin> maybe add links, like "This article is for kernel 2.6.XX. For this kernel version 2.6.OLD, use this revision"
      • <quantumsummers> at some point, it will need an "unmaintained" mark
      • <hwoarang> deprecate or mark something as unmaintained it is more preferable than deleting an article
• <ni1s_eee> i've found that its easier to seperate bits after portage seperation of stable and testing, and not specific versioning

<winterheart> How about i18n then?

• <winterheart> fr.wiki.gentoo.org?
  • <hwoarang> or wiki.gentoo.org/fr
  • <quantumsummers> or wiki.gentoo.org/LANG
• <winterheart> then there must be wiki.gentoo.org/en first
  • <Mousee> We could probably setup a "dropdown" list of sorts on the main (english) page so you could set your language that way, first, and then later set it in your profile. But I haven't ever dealth with mediawiki's i18n setup before, so not sure if that would work well even.
  • <fekepp> for me it sounds good, english should be default, but wikis for other languages should be configured as soon as there are user willed to write in that language
    • <fekepp> and pages cross-linked

<quantumsummers> QA on the articles

• <Mousee> Just need others to review/critique it etc

<a3li> policies

• <Mousee> I'll be happy to write up some draft policies if we need a push in that direction
  • <hwoarang> http://gentoowiki.a3li.li/index.php?title=Gentoo_Wiki:Policies

<hwoarang> When are articles locked down?

• <a3li> edit wars.
• <a3li> or teams request pages to be locked (x11 if my memory serves)
• <fekepp> which leads to the question: who has the right to moderate, and how are they become moderators (and maybe somehow "controlled")
• <hwoarang> pages which describe core packages should be handled with care and restrict edit on them
  • <hwoarang> i was thinking about a core team actually
    • <hwoarang> consisted from 4-5 people. Like QA team or something
    • <hwoarang> like you do have modearators and super moderators
    • <hwoarang> this team will try to coordinate editors<->moderators<->gentoo projects
    • <winterheart> it is admins and bureaucrats technically

Open questions

• <a3li> the project is lead-less atm
• <a3li> differ from g-w.com?
• <quantumsummers> Who gets write access?
• <quantumsummers> Who are the editors?
• <ni1s_eee> artsy stuff, design and layout, templete style?
• <ni1s_eee> a IRC commit bot like g-w.com