On Jun 16, 2013, at 08:17 PM, Paul Boddie wrote: >> * Once we migrate we can probably get rid of the spaces. I think that's a >> Confluence-ism that doesn't translate as well to Moin. That should be >> easy enough to do manually, right? > >The only apparent purpose of the spaces is to separate the content and to >prevent name collisions, but I'm not sure there are any such collisions. >Maybe I can check this.
I'd be surprised if there were any collisions. Spaces seemed to be baked into Confluence, but for our modest wiki I never really saw much value in them. >> * We'll want a moderate amount of theming to be more consistent with the >> web site, but the latter also is in dire need of an update. >> >> * The top link on the FAQ page doesn't work. >> http://mmwiki.boddie.org.uk/DOC/Frequently%20Asked%20Questions > >Yes, that page has a name ending in a question mark, and the way I host this >publicly doesn't like that. It's a bug in mod_rewrite, and if I host it on my >own local Apache instance with full control over the configuration, I don't >get this problem. It will go away in future, I promise. :-) Cool. That's another thing to take notice of: are there any deployment issues we'd need to inform the python.org admins of? We already run a couple of Moins on that infrastructure, so I'm hoping that it'll be pretty easy to bring up another one. >Actually, I could have changed the page title generation to remove trailing >question marks for this exercise; I already shorten page names where the >filesystem would otherwise be upset (Moin needing to use the page names when >storing pages). That's probably fine too. >> * Only the FAQ 4 page has sub-FAQ numbers. (BTW, do you know of any Moin >> feature to make creating and managing a FAQ nicer?) > >I'm sorry but I don't quite follow the first sentence here. All of the pages >should show a list of questions in their respective section, but I see that >only section 4 has numbered pages. Is that what you meant? Yep. >The page names I take straight from Confluence, and you can see the same >phenomenon in the existing wiki: > >http://wiki.list.org/display/DOC/Frequently+Asked+Questions Yay. ;) >Of other Moin sites providing FAQs, I can think of the Mercurial Wiki: > >http://mercurial.selenic.com/wiki/FAQ > >Here, they use the Include macro to bring in subpages providing each section, >and the Moin TableOfContents macro is smart enough to see all the included >content and make a huge TOC. They could go further and also provide edit >links when including content: then, if anyone wanted to edit a section or a >question, they would be able to find the link for the subpage and do so; >editing the main page only really permits editing of the Include macros and >little else, as seen in the raw text of the page: > >http://mercurial.selenic.com/wiki/FAQ?action=raw > >As you can see from the existing translation of the Mailman Wiki, it's >possible to include many pages without having to name them all; take a look >at the last line of the following, which is used to drag in all the comments >on the page: > >http://mmwiki.boddie.org.uk/COM/Home?action=raw > >The ordering seems to be fixed on the page names concerned, however, making >it somewhat awkward if you prefer a different ordering, but we could always >provide a variant of the Include macro that supported other ordering >capabilities, I imagine. Oh, I'm just pining for Guido's old FAQwizard. It was nice to be able to just add questions and answers, with a minimal amount of categorization and ordering, and then have them all collected and formatted correctly. It's not that big of a deal - I was mostly wondering how other projects maintained their FAQ. >> * How will we control wiki spam on the new site? Right now, we allow >> anyone to sign up and read, but they must request write access. When they >> do, we add their userid to a special group that has write to any wiki page >> (except the currently unused private pages). Can we have the same setup >> for Moin? I think it's *probably* okay to just have people re-request write >> access after a migration (no need to automate the user/group migration I >> think). > >Moin is very flexible about access control, so we can almost certainly >support what is needed. As for registration, I think there are extensions >that require people to verify themselves using e-mail - the Debian Wiki may >be using this, I think - and it's probably completely feasible to support >this kind of mechanism. > >As for migration, I haven't looked into this, but I don't see too many >problems at least replicating the Confluence accounts, even if we can't >migrate all the details. Sounds good, thanks. >(I think it's interesting to consider issues of authentication, and >coincidentally with respect to the Summer of Code work, I've been playing >with PGP-signed/encrypted interactions with Moin. So I look forward to seeing >what people come up with around such interactions with Mailman.) Me too! >> It seems to me the Moin wiki is pretty darn close. If Mark and others >> agree, I can start the ball rolling to request the necessary resources and >> DNS shuffles. > >My main concern is that I've missed some weird markup behaviour and that we >end up with pages where the markup is completely wrong throughout the history >of the page (both Confluence markup and the XHTML variant that Confluence 4 >and later use). But I'd like to think that I'm reaching the second half of >the exercise at the very least. ;-) > >Paul > >P.S. I can perhaps regenerate the site to work around the question mark >issue, if you want. Then, all of the content should be navigable. That would be fantastic, thanks. Let's wait for Mark's feedback and then we can start thinking about next steps. Cheers, -Barry _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9