Can we authorise users in some way? Perhaps they indicate they would like to join; we then e-mail them back with a code; and they use that to get in. Or maybe there is a delay before registrations occur. However, we don't want to put people off from contributing. I need to investigate whether a simple mechanism can be set up simply.
Decision: Adding actual hurdles only deters people. To begin with, we should let any one create a profile, and see if we get any problems.
When a users logs in, they get the UserPreferences page. Would it be sensible to change this to something like the FrontPage? It would probably be best to introduce a new configuration variable that sets this.
Decision: We should leave as it is as we want to avoid changing the code (see below). I've added a note about this to the GettingStartedWithTheWiki page.
Which theme should be used?
MoinMoin comes with three themes: classic, modern and rightsidebar. The default theme is modern.
If a user logs in, they can use the UserPreferences page to change the theme that is used when they use the wiki.
To provide documentation about how to use the wiki, it would be useful to force the use of a particular theme. We can do this by setting the theme_default and the theme_force variables.
One small reason why I prefer the monobook theme is that it has a Logout button. With the classic and modern themes, it is harder to logout: you have to find the appropriate button on the UserPreferences page. But maybe this is not an issue. I log out a lot because I want to switch to trying things out as an anonymous user or as another user that has different rights. So maybe I'm not typical. Do people have to log out?
The HelpOnThemes page points out that the classic theme is heavily based on CSS. If you are wanting to build a new theme from an existing theme, it is useful to know how complex the existing files are: the file monobook.py is 452 lines long, classic.py is 221 lines long and modern.py is 90 lines long. So, there is less to understand/maintain if you derive a theme from modern and your theme will then be close to the default. The HelpOnThemes page says that the theme API is not stable yet, and might change in the future. So this may be a problem if you provide your own theme. Somewhere it says that when you upgrade MoinMoin, the upgrade will not overwrite any themes that you have provided.
In making a choice about a theme, we ought to choose one that is accessible. The UserPreferences allows a user to choose a different CSS file but presumably that is only of any use if the HTML being generated is suitable for the use of CSS. It is possible to provide access keys and the Link macro available from the MacroMarket will help the use of this. I think that if you want to do this you would have to provide your own theme from scratch or override a lot of any base theme.
Decision: Choosing a third party theme means we run the risk of having to fix the code for it to work with the next release. Having said that, Jim Clark does seem to be fixing bugs in the monobook theme. We should adopt the default theme (modern), and change theme_force to force this on all users.
How to add a discussion page?
Other wikis have discussion pages or talk pages. I have been experimenting with using a subpage called .../DiscussionPage for discussion pages. And have altered the monobook theme so that it has a tab called Discussion. I have since found that other people using MoinMoin have used a subpage called .../Talk for the discussion page. Note: they use Talk because mediaWiki has a Talk: namespace. I have also seen sites providing a DiscussionPageTemplate.
Decision: A tab labelled Discussion was something I added to the monobook theme. Because we have decided to adopt the modern theme, it won't appear. When creating a page containing a document, we need to remember also to create a subpage called /DiscussionPage and link to it from the document's page.
Providing house rules
I've altered the code of MoinMoin so that when you click on Edit it outputs the house rules for adding a comment to the page immediately above the edit pane. These house rules are only output if it is a DiscussionPage.
This was done by editing the file PageEditor.py adding a section of code starting with:
if preview is None and self.page_name.endswith('/DiscussionPage'):
I worry about the long-term management of editing core files like PageEditor.py. It would be better to do this with a configuration variable. Such a change is more worthy of being fed back to the MoinMoin people.
Decision: Because we are not altering the code of existing files (see below), the only thing we can do here is to put any house rules at the top of any wiki page we create.
The text about licensing
I've altered the settings of the page_license_enabled and page_license_page variables. This causes the text:
By hitting Save Changes you put your changes under the XXX.
If you don't want that, hit Cancel to cancel your changes.
to come out just above the Save Changes button. Randy comments that this is not very obvious as the text does not stand out. It's not in any special piece of HTML and so it would be difficult to configure this differently through a change in the CSS. I would prefer the text about licensing to appear just above the edit pane possibly through the use of the new configuration variable mentioned above. If the configuration variable allowed any HTML, then it could easily be configured through CSS.
Decision: Note but ignore Randy's comments. We should use the page_license_* variables. What is the name of the licence should I refer to?
Headers and footers
We need a footer to say who we are and who we are funded by.
I've currently configure silly text to come out in the header1, header2, footer1 and footer2 positions. But they appear all over the place and sometimes not at all. And it all depends on what theme is selected.
Decision: We should set the header1, header2 and footer1 variables to the empty string. Should I set footer2 to the text OSS Watch is funded by the Joint Information Systems Committee?
I've also sillyly altered the credits line. This seems to always come out OK.
Decision: What credit URLs do we want?
Whilst looking at why a wiki page that uses the FeedParser macro was not being refreshed when the feed changes, Randy and I discovered that pages are cached.
To me it appears that the caching algorithm is based on how long it has been since the feed was last changed, meaning that a feed that is changed often does not get cached for long. I could not find the caching algorithm in the code of MoinMoin.
I think the cached version is stored in a file with a name like pages/BarryCorneliusRssFeeds/cache/text_html. There is a Delete Cache button on the LHS of each wiki page (if the monobook theme is being used). This seems to go and generate the page again and so the timestamp on the text_html is then up-to-date. I presume that this discussion is applicable to all wiki pages and not just those connected with RSS feeds.
I notice that on other MoinMoin sites the Delete Cache button has the name Refresh Cache. This is probably better. However, my view is not supported by the webpage at http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.3/CHANGES where it says they renamed Refresh to Delete Cache as it was misused by users.
Whether it is delete or refresh, it implies to me that the whole of the cache is removed. What I think actually happens is that it refreshes just its copy of the current page.
Decision: There is nothing to decide here.
Subscribing to pages
If you subscribe to a page, you get a message when someone other than yourself edits that page. On the Edit page, there is a Trivial change checkbox. If the person editing the page decides to select this checkbox, you will not get the message, unless you have selected the Subscribe to trivial changes checkbox on your UserPreferences page.
There is a configuration variable (mail_from) that can be set to whatever the MoinMoin administrator wants to appear on the From: line of each message. We have it set to firstname.lastname@example.org. All messages that are sent not only have this address in the From: line but also in the To: line. The code (in /usr/lib/python2.3/site-packages/MoinMoin/util/mail.py) explains that it does this so as not to expose the e-mail addresses of the other subscribers. However, I don't think this address actually gets the message (which I don't really understand).
Decision: We need to set up a fictitious user that gets by e-mail the changes (including trivial ones) to all of the pages.
How do we use the web site and the wiki site?
Do we move all the content of the web site to the wiki site? Do we replicate some of the content of the web site in the wiki site? If a paper appears on the web site, do we add a footer to that web page that links to a discussion page on the wiki site? Do we remove the e-mail address for feedback from the web site and replace it by a link to a wiki page? Will people prefer to e-mail us (knowing that the communication is initially private) and add comments to a wiki page (where the communication is public)?
Decision: We can decide some of this stuff at the Love-in.
I need to review the documents and the functionality of the proto software catalogue and see whether its aims could be met through the wiki.
Decision: This has not yet been done.
Briefing note about the wiki
When the wiki is launched, we need a briefing note about the wiki, indicating what features it has and how it will be used.
Decision: This has yet to be done.