[19:04:42] astaecker: so, the meeting was your idea. I guess we're ready when you are :) [19:05:19] Ok. [19:05:24] lets go [19:05:27] role call [19:05:49] -*- hwoarang here [19:06:02] here [19:06:07] -*- disi listening only :) [19:06:12] not here, obviously [19:06:16] !herd wiki [19:06:18] hwoarang: No such herd wiki [19:06:22] bah [19:07:20] -*- knipwim listening [19:07:56] well i'm here [19:09:32] Our topics are here:http://wiki.gentoo.org/wiki/Gentoo_Wiki:Progress#Topics [19:09:40] Lets do one by one [19:10:07] 1. mission statement [19:10:31] draft mission statement is here: http://www.gentoo.org/proj/en/wiki/ [19:11:12] the real goal is to allow devs to write quick documentation and get rid of guidexml [19:11:17] -*- hwoarang tbh [19:11:33] devs+users ofc [19:12:47] I'm OK with the text [19:12:53] yeah, me too [19:13:31] it's not about docs, or replacing guidexml, imo. we shouldll not be fishing in the waters of the documentation team without them wanting it [19:13:35] -ll [19:14:45] true for now :) [19:14:48] -*- tove is here too [19:15:32] But it should be fine to write another page about same topics. [19:16:12] ? [19:17:34] If you want to write a better/more complete/... article about e.g. portage, you should do it. [19:18:10] ppl are already doing it [19:18:24] not extend existing ones? Or better first place a note into the discussion? [19:19:18] i dont follow [19:19:52] Extend pages in the wiki, but start a new wiki page, if only guidexml page. [19:21:28] I think we are fine with the draft mission statement. [19:21:34] next: 2. relationship to gentoo-wiki.com [19:21:54] We need an official wiki, because most developers will not commit to g-w.com [19:22:02] As g-w.com will not move, we have to duplicated pages / do our one thing. [19:22:18] s/one/own [19:22:23] true [19:22:30] not duplicate as in copy-paste [19:23:56] i copied the only page i was maintaining at g-w.com to the new wiki [19:24:18] and updated templates, made a general revision [19:24:45] and put up a text on g-w.com version that i was maintaining it further at the new wiki [19:25:05] If you writen the page yourself, you are free to relicense it. [19:25:16] yup [19:26:06] perhaps a guide for copying from g-w is in appropriate [19:26:18] RMS would say, it's only documentation... [19:26:39] gentoowiki.com is so often unavailable.. i don't get why he don't want to work with us [19:27:15] I made a cheat sheet for swappers: http://wiki.gentoo.org/wiki/Help:Gw.com_cheat_sheet [19:27:22] We can extend it [19:27:59] i was referring to the copyright thing [19:28:29] we can add it [19:29:52] yeah useful detail [19:31:26] Next: 3. Spam protection [19:31:54] I'm fine with both user registration and the captcha. The additional captcha will safe us some spam. [19:33:25] i agree [19:35:18] Ok, now some more interesting stuff: [19:35:21] Next: 4. Navigation [19:35:57] Normal is the use of categories. [19:36:08] re 3. does a new user needs to activate his account first (via mail)? [19:36:41] no. an email address is not required. but if a user does not provide an email address they can not a) recieve email notification or b) get their password reset [19:36:54] if they do provide an address, it is verified [19:37:20] wouldn't it make sense to add mail activation as well? [19:37:44] I guess that'd create quite an obstacle for very privacy-aware people [19:38:24] 4. project portals << does that mean like x86, amd64, ARM etc. ? [19:39:06] I think the current way is a good compromise between lost contributions from not wanting to create an account and spam protection and accountability [19:40:15] disi: Portals means existing gentoo projects / herds. And there is a x86, amd64 herd. [19:41:53] Are there any open questions about spam protection? [19:43:48] Ok, now 4. Navigation: [19:43:53] So, should we group pages in categories and assign categories to herds? [19:44:24] Or should we just use categories? [19:45:03] why assign categories to herds? [19:45:10] for the herd categories idea, what about pages for which no herd is applicable? [19:45:53] knipwim: we can create a misc herd [19:46:40] i don't think you need to assing pages to herds [19:46:46] i dont see the reason [19:46:54] so categorry X11 could be assigned to several herds? [19:46:54] I don't get the idea still and would like some explanation [19:47:12] yes please elaborate a bit [19:47:38] The reader goes to main page [19:48:01] On the main page are the portals / herd listed [19:48:16] He clicks on e.g. "Desktop" [19:49:27] He sees some infos about the herd (developers, news, open bugs) and the related categories and featured pages [19:49:39] He clicks on featured page "KDE" [19:50:59] i dont quite see the reason for this overhead [19:51:14] k.i.s.s [19:52:06] Integration / promotion of the herds. [19:52:30] the herds are a developer perspective, so perhaps this structure is a good way to let the users experience this [19:52:42] you add extra work for herds [19:52:58] they already have to maintain their project pages [19:53:02] we can do that portal/herd idea, but I don't see the direct correlation with the category system [19:53:07] why add extra work for them [19:54:22] astaecker: would the herd teams have to maintain their pages? [19:55:45] -*- disi thinks from the administration point of view, only categories for now and once it developes those pages are easily assigned to herds(if they will be used) [19:55:46] knipwim: no, but they can - if they want - take the editor part. [19:57:38] a3li: it's about navigation. The categories should not be grouped under "herd" categories. [19:58:22] I'm not sure I follow [19:58:32] me neither [19:58:42] I think we're discussing two things at a time currently [19:59:47] one is how to create a category hierarchy in which the articles are put, and the other is whether and how to present one selected category in form of a portal that exists per ebuild herd [20:00:33] right, I'm talking about the second point. [20:00:47] So forget a the moment the portals/herd idea. [20:01:44] The question still is, how to guide the user to the articles. [20:02:24] We then need some top-level categories and add them to the main page. [20:02:34] Right? [20:02:56] sure [20:04:10] So what are these top-level categories? [20:04:35] dekstop/system/media/misc/ [20:05:34] not more than 7 [20:06:51] installation? [20:07:22] it is covered by handbook isn't it [20:07:31] and can fall into the system category [20:07:39] *it can [20:07:41] if needed [20:08:48] science? [20:09:10] is there a real need to science articles? [20:09:17] i dont know i am asking [20:09:20] true [20:09:32] just browsing through all herds [20:10:12] imagining all herds being part of one of the four you mentioned [20:10:40] for top-level 'tags', I'd go for something like this: core system, software, hardware, desktop, server and security, project and community [20:10:44] the top level should be few and very general [20:11:04] a3li: yeah good approach [20:11:16] there is prob an overlaping [20:11:20] intended [20:11:34] software <-> deskop server<->hardware or something [20:11:45] what is the scope of software [20:12:26] all kinds of software [20:12:45] some of the software, like I don't know, bash is part of core system as well [20:12:55] as would be libata both core and hardware [20:14:34] OK [20:14:49] taking your herd/project portal idea into this, it should be a different 'category structure' [20:15:14] we can take selected articles, and just slap the 'featured in herd XYZ' category on it to have it in there [20:16:01] all pages could have categories for different category structures [20:16:44] well, tagging [20:19:50] OK, I think we are done with the navigation topic. We will create a3li's top-level categories and see how it goes. [20:21:07] also some kind of definition for each category? [20:21:39] or some examples of what should be in them and what not [20:22:46] Writers will see it, when there some pages categorized [20:24:40] kk [20:25:35] Next topic: 5. i18n [20:25:57] We have the "translate" extension. [20:26:15] It is a top-down approach. [20:26:49] You write an english article and that can be translated into other languages. [20:27:08] So you only have to quality control the english article. [20:27:20] I don't know any good translator ;) [20:27:20] how accurate is that? [20:27:45] There is no automatic translator. [20:27:45] hwoarang: think of it like gettext per-paragraph [20:28:00] i see [20:29:23] If it's not automatic, how translation can be keep in sync ? lot of work [20:29:40] (and not really fun work...) [20:29:45] The extension manages the version control [20:30:30] users see on a special page, what needs to be done. [20:30:32] astaecker: when you commit a change does this tool also merges this change to other languages? [20:30:35] And this mean user who don't write english can't write howto [20:31:57] hwoarang: the missing parts appear in english [20:32:11] ah [20:32:17] Ycarus: yes [20:32:22] Ycarus: the problem is with the wikipedia-style i18n that every article is completely different [20:32:31] and we've had quite some people in the project who didn't want that [20:32:40] a3li, it's the case with g-w.com ;) [20:32:44] their initial request was to have an english-only wiki [20:33:05] ok, so I will never contribute I think, and I will keep fr.g-w.com ;) [20:34:57] a3li: so this isn't a question, but a statement :) [20:35:15] ? [20:35:30] Ycarus: you're free to do that. but I hope you can see the problem that we're trying to avoid. [20:35:43] I mean, there will be only English articles and a translated page [20:36:00] Ycarus: besides, you don't need to know english perfectly to write an article, there are others who can fix your mistakes and you can even learn from that [20:37:09] I don't really want to write in english, it's not my language ;) [20:37:14] disi: you mean to say why this discussion topic? [20:37:23] jupp [20:37:45] but good as info [20:38:25] http://wiki.gentoo.org/wiki/Gentoo_Wiki:Progress#Topics << here are still two suggested solutions, but I would also go for the automatic translation [20:38:48] I hope now you understand why a lot of *.g-w.com admin and contributors will never contribute to officiel wiki and will keep g-w.com [20:39:24] Ycarus: if everyone is as stubborn as you, that might very well be the case. [20:39:35] perhaps this discussion could serve as translation documentation on the wiki [20:39:48] Ykarus' question is bound to be asked again [20:40:08] Good idea [20:40:44] a3li, it's not really the case, you don't understand... It's very difficult to a lot of people to write or read english so... [20:40:59] let's just drop the subject here [20:41:09] is there a way to have original articles in French, English, German and they can be translated into the other languages? [20:41:12] sorry [20:41:39] OK, next topic: 6. Help pages [20:41:40] that's not how it works, no [20:41:44] one more thing [20:43:44] I just want to make it clear that we might risk original contributions in foreign languages, but it should improve quality and reduce outdatedness of the articles [20:44:01] from what I've heard, it worked quite well at the kde wiki [20:44:20] userbase.kde.org [20:44:23] yeah [20:44:41] we can do something like offering help to write english articles for people with problems with the language [20:46:13] if we see that it doesn't work out at all, we can talk about another system to do i18n [20:46:28] for the moment, it is what combines all of the several positions and interests on this topic the best [20:46:35] i agree [20:46:43] me too [20:47:08] for the record, this isn't discrimination in any form, but a try to get high-quality up-to-date documentation for primarily english (it is the language of linux, open source, the world anway) and as many other languages as possible [20:47:25] not really the language of the world ;) [20:47:47] yeah, let's do a chinese wiki [20:47:54] can you be helpful or quiet, thanks. [20:48:08] Maybe some tag or category, like astaecker set up in the German g-w.com "for review" or something... [20:48:18] we'll see that later on I guess [20:48:21] okay, I'm done now [20:48:30] lol [20:49:25] Next topic: help pages [20:49:38] The Mediawiki project maintains an user guide about the mediawiki software as public domain. We should import it instead of linking it. Then we can change the bits that are different in our wiki. [20:50:07] why importing it as a whole? [20:50:20] we can just write down the bits that are different [20:50:22] *different [20:50:48] The user has to merge the information. [20:51:21] I guess we can copy it, yeah [20:51:24] It would be more helpful and less error prone [20:52:05] ok [20:53:30] Next topic: Who can edit? [20:53:59] At the moment we have only user registration. [20:54:17] creators should be able to edit their articles [20:54:21] (apparently) [20:54:27] "everybody" should be able to read/write english nowadays and people who can't shouldn't use linux at all [20:54:39] idl0r, thanks [20:55:14] let's stay on topic [20:55:17] we prob need to form a reviewers team? [20:55:25] that's part two [20:55:28] right [20:55:30] kk, i will be quiet now :P [20:55:37] maybe all devs can edit? [20:55:41] by default [20:55:43] everyone should be able to edit [20:55:47] I hope everybody could edit [20:55:49] a3li: everything? [20:56:11] yes, except for important pages (front page, widely-used templates) and pages having edit wars, etc [20:56:21] yeah [20:56:28] moreover, there is the vcs history [20:56:32] it's a collaboration software after all [20:56:34] so we can keep track of edits [20:56:40] if needed [20:56:45] one other exception might be project-specific namespaces that projects request [20:56:55] we can restrict editing there, and everyone not in that team can use the talk page [20:57:49] ok [21:01:00] astaecker: anything else there? [21:01:02] We should document in the help pages, which pages are restricted. [21:01:15] Next topic: Quality control [21:01:34] There is the "flagged revisions" extension. [21:01:52] It shows at default only the reviewed version of a page. Only reviewers (this is a user group) can mark newer page versions as reviewed. Pro: Users see only the reviewed informations; contra: We need ppl who do the reviewing. [21:02:11] I'd probably go without that in the early stages [21:02:41] exactly because of that effort [21:02:56] OK with me [21:03:51] contra: the authors might becomes frustrated? [21:03:55] -s [21:05:24] that too [21:05:27] true [21:05:56] I think, we are now out of planned topics. Any other topics? [21:06:09] a3li: I would to be a "translator", maybe also with "pagetranslation" rights to start the german i18n stuff going. [21:06:30] that can be arranged [21:06:39] one more thing, "grand opening" [21:06:41] great [21:06:52] how/when should we announce the wiki? [21:07:39] what's stopping us? [21:07:59] someone would have to write an announcement [21:08:14] Categories and help pages are need to be done [21:08:16] and I guess I would want to have some basic categories up [21:08:16] yeah i mean are there any implemetation blockers? [21:08:22] ok [21:08:27] so lets say a week from today? [21:08:30] next sunday [21:08:40] should be ready by then [21:08:58] and we have more material now that it is semi-opened [21:12:46] sounds good [21:12:56] good [21:13:01] I guess I have to take care of importing the help pages [21:13:23] :p [21:14:05] If normal users can do mass imports, I can do it for you. [21:14:28] I don't think you can [21:18:06] If there is anything more, I end the meeting.