[23:00:40] lets go [23:01:14] roll call [23:01:15] -*- hwoarang here [23:01:20] . [23:01:23] moo [23:01:34] everyone?;) [23:01:35] heyo [23:01:40] here [23:01:42] just leaving :| [23:01:46] !time [23:01:46] opcode0x90: use time set to set your timezone. [23:02:15] -*- tove too [23:02:28] oi [23:02:35] hello [23:02:42] Decent turnout. [23:02:47] indeed [23:03:36] before we go into wiki technical stuff [23:03:39] <-- yporti (~yporti@hyadesinc/fieldmarshal/yporti) has quit (Disconnected by services) [23:03:43] <-> yporti_ is now known as yporti [23:04:07] here [23:04:08] --> yporti_ (~yporti@hyadesinc/fieldmarshal/yporti) has joined #gentoo-wiki [23:04:14] we need to cooperate with the infra ppl and decide how to handle the infra services [23:04:42] robbat2 stated a couple of days ago: [20:04:54] hwoarang, i had asked for details of what you needed, and the initial mediawiki config, and instructions to add it with webapp-config [23:05:21] <-- yporti (~yporti@hyadesinc/fieldmarshal/yporti) has quit (Quit: Leaving) [23:05:22] i don't know if this is possible, but I assume that we can work on a3li wiki page and then sent the configs file to robbat right? [23:05:31] <-- yporti_ (~yporti@hyadesinc/fieldmarshal/yporti) has quit (Remote host closed the connection) [23:05:41] basically, we let cfengine install mediawiki, then webapp-config "install" it by hand and hopefully you have a git repo with configuration files [23:05:51] +1 [23:05:57] work directly on infra machine? [23:06:01] hwoarang: Minus a few minor config changes, ya [23:06:11] i dont mind [23:06:15] no, you won't have access to the infra machine [23:06:23] maybe we should start with basic questions rather than implementation details. [23:06:25] i mean , work directly on wiki located on infra machine [23:06:37] a3li: please proceed [23:06:39] we still have no policy drafts, no mission statement. [23:06:51] no timeline. [23:06:57] we've a "draft missions statement", that's about it [23:07:00] *mission [23:07:06] we got out of timeline since Ben left [23:08:05] the mission plan is to host an official wiki on our infra machine [23:08:15] -vvvvv [23:08:19] that was the original plan [23:08:19] "an official wiki" [23:08:23] what contents does it have? [23:08:28] how does it differ from g-w.com? [23:08:36] there is the issue of who gets write access. qa on the articles, who are the editors? [23:08:44] -*- hwoarang taking notes [23:08:55] I'll be happy to write up some draft policies if we need a push in that direction (rather than assigning it to someone who may not be interested). [23:08:57] -*- quantumsummers would like to think of this as a collab space for docs in progress [23:09:08] Just need others to review/critique it etc [23:09:15] then the wiki doc gets guildexml-ified [23:09:47] quantumsummers: that was a huge conversion on month ago [23:09:58] if we need to write everything on guide-xml [23:10:04] I would be happy to assist with writing the converter using mwlib [23:10:05] *guild [23:10:32] excellent [23:10:59] there's no intention to convert everything to guidexml, the wiki is supposed to be separate from official documentation [23:11:16] like expand it or cover different aspects [23:11:18] ? [23:11:31] probably a bit of both [23:11:40] I have most of that in place anyway ... the converter that ius [23:11:42] *is [23:12:00] 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 [23:12:01] i dont mind converting articles to docs [23:12:08] that's what the wiki is for [23:12:22] spatz: no but it would be nice if we could convert a nice article to doc [23:12:31] of course, I'll never be against that [23:12:38] spatz: I agree, not everything. However, important docs can be worked up in the wiki, then with docs team, migrated into official' [23:12:45] a3li: answering your question, wiki could be a nice place for devs+users to cooperate [23:12:57] nod [23:13:01] using bugs+cvs for docs like we do now is not an option [23:13:02] --> yporti (~yporti@hyadesinc/fieldmarshal/yporti) has joined #gentoo-wiki [23:13:14] cooperate on what? [23:13:17] even with beacon, its not easy [23:13:18] docs [23:13:24] a3li: writting documentation [23:13:48] until now, if a user wanted to write a document, we had to open a bug, attach the diff file, and wait for docs team to merge it [23:14:04] wiki will make that a lot easier [23:14:23] even for us [23:15:21] another use would be for devs: writing agendas for meetings, writing summaries, drafting news items etc. [23:15:21] because it is a lot more easier to write articles based on wiki formats rather than guildexml [23:15:35] spatz: yes, that is a good use [23:15:46] And its easier to keep documenttion up to date that way [23:15:51] nod [23:16:07] hwoarang: exactly. One of the reasons I think most people are afraid to offer additions/fixes. [23:16:16] esp if we have a little python to convert to xml, easy updates [23:16:33] right [23:16:52] now, has anyone here used beaconeditor? [23:16:53] of course we can use wiki in both ways, like writing base documentation and some cool tips and tricks etc [23:17:23] its a possibility we could use that as the wysiwy* editor in there [23:17:53] perhaps that is a point for a later discussion [23:18:00] indeed [23:18:01] i guess [23:18:12] tabled [23:18:19] so we collaborate with users on documentation and draft meeting agendas and news items. [23:18:22] what else? [23:18:38] there is an events plugin, so meeting planning [23:18:53] calendar in general, conferences [23:19:00] so we collaborate with users on documentation and plan and manage meetings and draft news items. [23:19:15] I like what you are doing there [23:19:19] :p [23:19:19] lol [23:19:32] i dont think we should make it too complicated [23:19:35] what else is there to do with a wiki? [23:20:03] Determining and setting up templates for one. [23:20:06] hwoarang: KISS it is. but we shouldn't start builidng that wiki recklessly and with no clue what we /want/ [23:20:18] a3li: yes [23:20:31] think about more special cases too, like a special combination of packages + configuration. that's maybe not general enough for an official doc page, even if it is good documented, so the wiki would be a good place [23:20:44] it is proven that extra time spent in the analysis and planning phases of a project result in less time spent in implementation. [23:20:53] --> dansan (~daniel@ppp-70-242-114-8.dsl.rcsntx.swbell.net) has joined #gentoo-wiki [23:20:57] of course [23:21:16] in that line fekepp, it might be nice to document "workarounds" perhaps [23:21:34] dont we have forums for that? [23:21:40] yes [23:21:48] and why use workarounds for ebuilds. just fix them [23:21:48] :p [23:21:50] that can be a morass at times [23:22:01] time dependent, as they will be invalidated by bug fixes [23:22:14] Perhaps workarounds as in "Things that haven't been fixed by upstream yet"? I dunno [23:22:14] Are we not supposed to use the word HOWTO in article titles? I'm not seeing other articles that do & I'm writing one. [23:22:47] that is sometimes taken as a category [23:23:03] ok [23:23:17] a3li: please restate your collection for us [23:23:46] so we collaborate with users on documentation and plan and manage meetings and draft news items. [23:23:52] not sure what to do with the "workarounds" [23:24:00] axe it [23:24:18] needs better formalization [23:24:23] indeed [23:24:27] --> rafaelmartins (~rafael@unaffiliated/rafaelmartins/x-162351) has joined #gentoo-wiki [23:24:38] i cant think of anything else [23:24:58] then :w [23:25:00] Well again, what about templates that are to be used? [23:25:02] if there is somebody who has time to write some qualified docu about something that is worth enough to write about it is good. connected to perhaps a lot of those documents the question of wiki-structure becomes more important, e.g. categories, index, etc. [23:25:21] How are we going to determine which ones to add and which ones not to bother with? [23:25:38] 'templates'? [23:25:58] templates are predefined formats for some kind of text [23:26:08] Templates as in {user|date|comment} and such. Give me a sec and I'll grab an example. [23:26:19] ok. so we need a list of needed articles and their hierarchy. [23:26:27] http://en.gentoo-wiki.com/wiki/Index:Templates [23:26:29] this is way too hard to define it [23:26:34] templates like that [23:26:49] quantumsummers: at least about needed categories, and of course important articles [23:26:57] yes, we need that [23:27:42] categories and structure. let's talk about that. [23:28:05] we could base it off of the existing doc structure http://www.gentoo.org/doc/en/ #2 [23:28:16] expanded http://www.gentoo.org/doc/en/list.xml [23:28:46] perhaps off of system profiles [23:28:51] i like that stracture [23:29:10] thing is that wikis are not quite made for taxonomies [23:29:41] we basically can do one level of proper subclassing with namespaces [23:29:56] that is all? only 2 levels? [23:30:24] as a wiki evolves also the structure evolves, but a wise choosen structure at the start which can be extended later could be useful [23:30:54] quantumsummers: we can fake a hierarchy. but it'd still be faked. [23:31:05] ok. [23:32:06] does media wiki support some form of tagging? [23:32:14] It has categories [23:32:32] categories work. there's other tagging solutions as well. [23:32:39] in my opinion the structure at the beginning should cover the most general parts of possible articles, it should be not too special (extended later) to get not lost [23:32:44] (including a full-blown semantic web extension) [23:32:46] Ya categories are essentially "tags". You can have several types of categories listed for a single page. [23:33:12] beside categories there are indexes too [23:33:30] cool [23:33:39] the index pages should be used extensively [23:35:06] ok [23:35:15] anything else? [23:36:04] how would pages describing multiple package versions be dealt with? [23:36:27] as in, when would information for old packages be cleaned off? [23:36:41] when the packages are no longer in the tree [23:36:44] I think it's a major problem with gentoo-wiki.com [23:36:46] i guess this is up to the editor to keep it up to date [23:36:57] --> slep (~slep@195.13.166.253) has joined #gentoo-wiki [23:37:08] so we've slipped into policies [23:37:15] silently [23:37:26] http://gentoowiki.a3li.li/index.php?title=Gentoo_Wiki:Policies [23:37:31] sorry if we're not there yet [23:37:49] it's fine. there was no agenda. [23:37:52] on g-w.com its often killed when it leaves the tree and diffrent version are talked bout under diffrent headings [23:38:30] sounds about right. I wonder if we should delete the articles or just mark them as "old" "depcreated" or what [23:38:40] some ppl might have very old systems [23:39:58] one thought to the lines above: keep in mind that a wiki much more dynamic than static docu, it evolves. there should be a framework of guidelines which but everything in the right direction but do not make it difficult for ppl to write (/me makes a coffee now) [23:39:58] as an example, I recently used the nouveau guide (a fairly new article). In one page, it tries to describe three versions of how to install nouveau, all intermingled together [23:40:21] It's extermely difficult to follow [23:40:31] 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. [23:40:36] --> lk4d4 (~lk4d4@mail.gentoo.ru) has joined #gentoo-wiki [23:41:11] the word 'duplicated' made me twitch [23:41:30] there's the revision history. people needing old info can see old revisions [23:41:34] amoskvin, sometimes it takes awhile for an article to find its "flow", especially if its an article on X stuff for some reason [23:41:36] it's a copy of the document as it was, before the old version was removed [23:41:55] a3li: That's what I would say. Makes things much easier. [23:41:56] a3li: +1 [23:43:01] When are articles locked down? [23:43:03] a page with with really old stuff could just have a {{Warning}} at top [23:43:05] maybe add links, like "This article is for kernel 2.6.XX. For this kernel version 2.6.OLD, use this revision" [23:44:28] at some point, it will need an "unmaintained" mark [23:44:45] indeed [23:44:46] i've found that its easier to seperate bits after portage seperation of stable and testing, and not specific versioning [23:45:00] <-- opcode0x90 (~opcode0x9@60.51.115.60) has quit (Quit: Leaving) [23:46:25] deprecate or mark something as unmaintained it is more preferable than deleting an article [23:46:33] 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 [23:46:52] ni1s_eee: well if you take the nouveau page, which would be the one for testing? With kernel 2.6.33 or 34_rc? It's not really thar clear-cut infortuantely [23:47:01] *unfortunately [23:47:48] 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. [23:48:32] yes of course, i would suggest to keep only text about in-tree-versions [23:48:39] amoskvin, yeah thats not really possible for that article, as nouveau is so new, [23:48:45] fekepp: yes [23:49:19] 22:42 <@hwoarang> When are articles locked down? [23:49:21] ^ [23:49:24] edit wars. [23:49:39] heh [23:49:53] or teams request pages to be locked (x11 if my memory serves) [23:50:12] I agree [23:50:20] ya that makes sense [23:50:20] <-- lk4d4 (~lk4d4@mail.gentoo.ru) has left #gentoo-wiki [23:50:31] which leads to the question: who has the right to moderate, and how are they become moderators (and maybe somehow "controlled") [23:50:33] pages which describe core packages should be handled with care and restrict edit on them [23:50:47] i was thinking about a core team actually [23:51:17] consisted from 4-5 people. Like QA team or something [23:51:42] like you do have modearators and super moderators [23:53:47] this team will try to coordinate editors<->moderators<->gentoo projects [23:55:06] <-- slep (~slep@195.13.166.253) has quit (Ping timeout: 246 seconds) [23:55:07] it is admins and bureaucrats technically [23:55:15] by the way, one unrelated question: what will be the url? wiki.gentoo.org? [23:55:24] likely [23:55:36] --> slep (~slep@195.13.166.253) has joined #gentoo-wiki [23:55:49] would be most intuitive;) [23:56:07] indeed [23:56:58] how about i18n then? [23:57:10] fr.wiki.gentoo.org? [23:57:24] or wiki.gentoo.org/fr [23:57:28] or wiki.gentoo.org/LANG [23:57:34] latency [23:57:40] ;0 [23:57:43] <-- crimer (~crimer@p54A07452.dip.t-dialin.net) has quit (Ping timeout: 276 seconds) [23:57:44] i dont know how wiki handles i18n [23:57:58] not. [23:58:04] then there must be wiki.gentoo.org/en first [23:58:13] besides having a way to link to other languages. [23:58:40] i see [00:00:00] - {Day changed to Tue May 11 00:00:00 2010} [00:00:25] so 1 hour passed, should we stop here, update the wiki page and start working on several stuff from now on? [00:00:37] something for the ppl who go into the technical details. but more abstract: there should be a multi-lang wiki? [00:00:46] hehe [00:01:10] (the project is lead-less atm, too) [00:01:11] oh, the artsy stuff, design and layout, templete style and such [00:01:13] (just btw) [00:02:10] fekepp: I think that's what we were talking about. Looking on mediawiki's site it seems they work as "wiki.gentoo.org/en", etc [00:03:14] 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. [00:03:27] 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 [00:03:37] and pages cross-linked [00:04:12] aye cross-linking would work like "{{Languages|MediaWiki/fr}})" [00:04:27] which would redirect to something such as: http://fr.wiki.gentoo.org [00:04:46] yes... i know it from wikipedia, so it should work somehow;) [00:04:49] nack on the linking [00:04:59] [[fr:Foo]] [00:05:06] interwiki [00:05:07] is what is built-in in mw [00:05:23] a3li: ya that's the template I just mentioned :P [00:05:34] that is not a template. [00:05:46] it goes in the sidebar [00:05:56] [[fr:Foo]] is calling a template [00:06:06] Mousee, link [00:06:12] http://www.mediawiki.org/wiki/Template:Languages [00:06:48] not what we're talking about [00:07:32] aye it's not the same template you're referring to [00:10:01] small notice: I have to get back to the army camp now but I will read the backlog later [00:10:38] hwoarang cheers [00:11:17] well we do have to talk about more stuff but I dont know how do you want to handle it [00:11:39] like start working on what we discussed or first define a clear design plan and then move forward [00:12:04] --> crimer (~crimer@p54A0CBBE.dip.t-dialin.net) has joined #gentoo-wiki [00:16:16] the concept of "portals" are interesting [00:16:21] <-- Quantum_ (~Quantum@78.86.91.0) has quit (Quit: Leaving) [00:17:11] we could have system, desktop, server, multimedia, security, hardware portals [00:18:49] yes, I would rather have that than ToC templates [00:19:31] as a general, high-level organization, how does that above sound? [00:19:38] need more, less, etc? [00:19:59] perhaps system, should be toolchain && system set [00:20:36] that can be further dissected for hardened & non-hardened [00:20:37] How are specific architectures handled then, in such a portal layout? [00:21:14] each portal has outlines for the arches [00:21:29] <-- slep (~slep@195.13.166.253) has quit (Ping timeout: 260 seconds) [00:21:49] profiles still seem to me a good way of organizing thing as well [00:22:02] another idea is to have them per purpose or endeavour, i.e system, web server, spam bot, etc. [00:22:32] Portals is maybe some replacement for existing projects on g.org [00:22:51] seems too large a set, to use a per-endeavor schema [00:23:31] the various projects could have portals, yes. or we have a portal for all projects, which are then represented in outlines [00:25:00] perhaps, i suspect there's going to be overlaps all over the place regardless of the portal 'mode' [00:26:45] quantumsummers: the later idea sounds more "user friendly", in terms of navigation, at least [00:29:34] <-- pbogdan (~silence@79-75-31-120.dynamic.dsl.as9105.com) has quit (Quit: WeeChat 0.3.0) [00:31:01] seems reasonable [00:31:59] at a point, we just have articles afterall, and then ways of getting to them. if we make a nice set of indices, and a good seach iface we'll be in business [00:33:38] that and a proper url [00:33:59] heh indeed [00:34:11] where i can found goals of gwiki ? [00:36:34] also, a IRC commit bot like g-w.com has would be nice [00:42:34] that should be easy