Talk:Proposal for Wiki Curator 3.20 Thomas Dukleth

This proposal troubles me greatly :(

I've been wanting to have a concerted effort focused on tidying up the wiki and making it usable again for some time and have expressed my opinions on a number of occasions.

I feel the biggest barrier to entry working on the wiki is the use of some pretty militant extensions that hinder effort rather than help it, and our reliance on a very old version of the software preventing the use of some of the more modern extensions and tools available.

I would prefer to see extension installation voted upon, with a clear proposal for their envisaged use before they're installed. The fact that you've also modified some extensions scares me even more as it blocks the simple transfer of wiki maintanence in the future, and you've not explained clearly at all what these modifications are meant to achieve.

I'm really pleased there's someone with a hope of getting things rolling on the wiki again, so please don't take all the above in a negative context.. but I do want a community effort rather than the continuance of the current situation.

MRenvoize 02:02, 17 December 2014 (EST)

Counter Method

If I had the time to work on this, my counter proposal would go along the lines of:

1. Spend some time taking stock, cleaning up very old pages
2. Migrate to MySQL as Postgres isn't well supported by Mediawiki, and using Postgres is blocking our use of many extensions and easy upgrade
3. Remove most of the extensions as many of them are interacting badly, preventing easy use of the mediawiki woftware, and preventing organic growth of our wiki [Organic growth is good, so long as it can be tidied and clean into structured content on a semi regular basis. We are achieving organic growth, hense the complete mess of pages we have now.. but with the extensions in place, even someone whose been using wikis for years really struggles to do any form of tidying/restructureing]
4. Upgrade Mediawiki
5. Vote on some core extension (My core proposed set would be, SemanticMediawiki, SemanticForms, ConfirmUserAccounts, SyntaxHighlight) (Others worth considering CategoryTree, DynamicPageLists, FlaggedRevs for curation) (One's I would vote against: CategorySelect - All it does it hinder page creation and encourage bad categorisation!, BreadCrumbs, BreadCrumbs2, CategoryBreadcrumbs - Having all these enabled just confuses the uses, obfuscates any usable navigation and makes life harder in general.. I'm not against ONE breadcrumb system however and would probably vote for CategoryBreadcrumbs)
6. Use the updated platform to tidy the current content, attempt to get a bit of a team together and teach them how to contribute to maintaining the wiki.

MRenvoize 02:11, 17 December 2014 (EST)

Telephone Discussion with Martin Revoize

I am adopting the suggestions from Martin Renvoize and I am in the process of adjusting my proposal accordingly. Migrating from Postgres to MySQL may be a critical component of that process and may be one on which Semantic MediaWiki depends to work correctly according to Martin. Some of the work especially, migrating the wiki to MySQL will require very careful testing. Everything cannot happen at once. I will change my proposal to include building up to that task. The complications involved in migrating to MySQL may require postponing the upgrading the wiki to improve the chances that the one procedure and set of migration scripts which I found would be likely to work. Above all, testing and more testing on a copy of the Koha wiki will be necessary to avoid the hazard of wrecking the production system without a way back for newly added content.

Returning from a winter break during which I had virtually no time of my own, which meant not enough time for Koha, I found that Martin had made some helpful suggestions which I had noted while away. Returning in January, I also discovered that over a year ago he created a brief outline with a few details for using wiki categories differently which my own neglect of wiki maintenance prevented me from discovering. [The page had no categories (using Martin's scheme or any other) and was consequently not readily findable without special knowledge for how to seek it. Routine wiki maintenance avoids such problems.]

I had a telephone discussion with Martin on 14 January and I will be happy to consult the experience which he and others have with how best to implement particular things in MediaWiki.

Martin had not participated in some of the history of the Koha wiki, consequently, some of his comments above missed the accident of history for how we have come to the current point. He may have misunderstood how some installed extensions actually work and the past problems which they have helped to solve. Understanding how the installed extensions were meant to work along with better maintenance can help all us poor humans to avoid some unhelpful inconsistencies in adding wiki content.

The MediaWiki test became the only Koha wiki after a misunderstanding with PTFS in which they took down the existing Koha wiki which was in DokuWiki. Under the circumstances, adoption was rushed at and I had no time to help properly with the immediate task of migrating. I had hoped to have time to test everything more carefully but there was not enough time before MediaWiki was the only Koha wiki running.

I had advocated Semantic MediaWiki as one of the great virtues of MediaWiki for which there was nothing sufficiently comparable in DokuWiki. Unfortunately in 2010, command line tests for using Semantic MediaWiki were failing on the Koha instance of MediaWiki. I suggested that we should treat Semantic MediaWiki as unsafe to use until we had taken the necessary measures to produce successful tests and not rely on the possibility that much of the user interface for Semantic MediaWiki might seem to work but we might discover that we had actually mangled the database and discovered it would not work properly with no clear path to fix it. Semantic MediaWiki has multiple associated extensions, such as Semantic Forms, etc., which need to work correctly with database changes implemented for using it.

I agree that the ordinary breadcrumbs extension is something which is better accomplished with a web browser extension and should be dropped.

The Category Breadcrumb extension which provides hierarchical navigation can seem redundant when there are multiple categories. In some cases, multiple category assignment is helpful for elucidating distinct important aspects of a wiki page. Category Breadcrumb is revealing some problems with redundant category assignment and improper category relationships which I have identified in my rewritten proposal. I will write some suggestions linked from the main page of the wiki about how to create category assignments which are helpful and not redundant in the same hierarchy. I consider Category Breadcrumb to generally be a great virtue which provides a helpful contextual navigation feature where users would otherwise have none.

I suggest that we keep the SelectCategory extension only until we have validated that Semantic MediaWiki is working correctly with Semantic Forms using whatever tests, including command line tests, which may be necessary. We should not rush to lose the authority control consistency which SelectCategory provides without being able to replace it with similar functionality from Semantic Forms. According to Martin, waiting for proper support of Semantic MediaWiki would entail waiting until after migrating to MySQL. He reports that some Semantic MediaWiki extensions do not work properly in Postgres. SelectCategory does not scale well which is why it cannot be used on Wikipedia. Semantic MediaWiki with Semantic Forms can replace it in due course, although, I may try extending Semantic Forms to provide something more helpful than guessing with auto-complete for authority control consistency. SelectCategory helps avoid a huge problem which we had when using DokuWiki in which the vast majority of wiki pages had no category assignment and no consistency of assignment and their content was mostly unfindable. The presence of the SelectCategory extension for the time being has never stopped people from assigning categories using the standard MediaWiki syntax to enter categories at the bottom of the page. However, in earliest testing, I discovered that an unfortunate effect of SelectCategory is that it would interfere with category links placed in the middle of a wiki page by creating the large selection form in the middle of the page in subsequent edits. Interference with placing category links in the middle of a page may be problematic in actual practise with Semantic MediaWiki and is yet another reason for discontinuing SelectCategory when it would be replaceable.

Similary to the case of SelectCategory, the Multi-Category Search extension should be replaced by the Semantic Drilldown extension after we have migrated the database to support Semantic MediaWiki.

First steps seem to indicate cleaning up some issues much as I had originally proposed. Later, moving on to MySQL migration; MediaWiki upgrade; then Semantic MediaWiki implementation.

Thomas Dukleth 20:50 11 Jamuary (UTC) with subsequent enhancements and corrections.