ToDo for 2017 Wiki Sprint
Please do also see ../Hackathon2017
Since basic editing is somewhat easy enough, authors rarely need to read the full documentation. As a result many features of the Wiki are not getting used. People seem to be frustrated about those perceived inabilities of the system. Hence documentation should not only be there, but be easier to access and consume in small bits.
- modify the syntax overview at the bottom of the editor page (the page containing the text editor field when you edit a page)
- include a short reference to features (see below), next to a syntax cheat sheet
Divide certain docs into very very small HowTos, possibly with further reading on a second page. Some questions that have come up during real world use are:
- How to include a table
- How to include an image (+position and scale)
- How to include an image gallery
- How to invite non-Fellows to edit a page (ACLs)
- How to attach files to an article (and reference them from within the text)
- also: how to let non-fellows upload files to the wiki
- How to set up private calendars or group calendars
- How to make an index (of headlines, and of subpages)
We should also attempt a complete ACL documentation, Moinwiki supports some very handy ACL features, that are not documented on the Moin website. It's time to read the source.
Moin does not really have multi language content support (there is multi language UI support, but that is entirely different). Our last brain storming in the FSFE office ended in the conclusion that a multi language Wiki will probably not be possible. Nevertheless Paul would like to venture into the field again, and collect possible practices for translating pages.
Many pages in the Migrated section have not yet found a home. Since in the mean time we have set up hierarchies, that were not there a year ago, we should try again to sort those pages.
We should also clear the redirection list. The rules can probably be simplified, resulting in improved web server performance.
Over the year we have probably come up with a good list of top level sections. The WikiAdmin section might not have made so much sense in the first place though, and maybe there are one two other improvements that could be made. Discuss! [Where? ~Guido ] ~doczkal: I would prefer to discuss this on the Mailinglist.
We should think about what plugins we may want to introduce, and we should think about working on the plugins we use. We should seek contact to the moin community to get possible modification upstream very quickly.
Evaluate https://moinmo.in/ParserMarket/ImprovedTableParser, which has been installed in the past.
Alternatively: Find and convert existing tables to current format
Guido: Even if there is a conversion script or could be easily written, future users would still have to maintain tables which lines will look like this:
||[http://www.koala.it/|Koala.it]]|| (./)|| || || IT<<BR>>(en, it)|| ||Mini-PCs (from [[http://www.koansoftware.com/|Koan]], who also seem to offer single-board computers]])||2015-12-19||
instead of this:
== [[http://www.lincomp.ch|Lincomp]] || (./) || (./) || ||CH<<BR>>(de) || ||Desktops, laptops and netbooks, compatible printers etc. ||2015-12-19 ==
Which syntax is more likely to encourage participation? (Sample lines taken from Migrated/Hardware Vendors
- Paul: Alright, I totally see what you mean, but actually the second syntax is not yet so pretty either
pboddie: There's flexibility in that table syntax: you don't have to put the column separators at the start of each line, for instance. The motivation with ImprovedTableParser is to make tables that don't need to have a row per line along with the accompanying restrictions that imposes on what can be put in table cells. For me, it was the one thing with MediaWiki that I missed from Moin.
Alternative 2: Moin supports some other markup languages, besides its own, and we wanted to look into markdown parsing anyway. Aside from looking into specialised table parsers, ,maybe we find a more common markup with better tables along the way.
- pboddie: Markdown is pretty underspecified - half the Internet seems to link to someone's blog post as the "reference" - and I doubt that either Markdown or any of the Restructured Text variants support decent table syntax. (Where "decent" does not mean having to manually align some plain text table representation.)
Find out how to run spell checking.
Make Moins RSS function more visible, e.g. see if the page style can be modified to show an RSS button in the top row.
We use the EventCalendar macro, and in regard t its usability this seems to be a good basis. Still there could be improvements.
- the string handling is bad, using "%s" in an event description may result in explosion, proper use of text formatting functions must be applied
- this may actually constitute a security flaw, so it is high priority
- It would be nice to be able to include pages by hierarchy, not only by category
- it would be good to have a way of exporting events as ICS file, and maybe as an RSS feed
this would probably require writing some sister plugin that understands the same syntax as EventCalendar
- the html markup is messy and makes styling difficult, simplifying the markup would result in simplified CSS, too
We use the Gallery2 parser, mostly because something similar was used on the old wiki, and the syntax was easy to translate automatically. The current version is slightly modified, because the upstream version includes some bloaty features that are a hassle to maintain on the server, and make for a bad UI. Since it is not really fair to propose patches that reduce features of the plugin, we could:
- find an alternative to this plugin
- fork it, or
- rewrite from scratch
Note: currently there seems to be a bug in the Gallery2 plugin which can cause pages to become unusable due to server errors.
As main requirements, the plugin should:
- produce thumbnailed versions of large attachment images for display
- Select multiple images at once (i.e. wild card on attachment names)
- Be able to attach comments to single images
- Clicking on an image should display of the full size attachment
What should not be included are:
(or in fact those are the points, that Paul finds unpleasing about the current solution)
- html tables, because this is wrong on so many levels
- fitting images into a table breaks any design effort to place them dynamically according to screen size
- images are not a tabular information
- image editing functions on the page, because
- content on a page is either edited, or viewed, not both at once
- modifying user provided files on the server is evil
if we must turn an image around for something, and the uploader is too lazy to do this in advance, we could provide a way, to pin a corresponding CSS class to an image
- an image slideshow, because
- wrap the gallery in some CSS class, and be done with this in a CSS three liner. There is no need to bloat up server side code for this.
Underlining and striking through text do currently not work
there have been some complaints about image placement, investigate!
- Second order heading appear larger than first order heading, also the heading style is inconsistent
- This emulates the style of the FSFE website, which suffers the same inconsistency
- It might be a good idea, to review this
Stuff for general discussion, not necessarily related to the wiki sprint:
Should WikiCaretakers be wiki admins?
Johannes and Thomas, please bring your SSH Keys