Update: This feature is in the process of being implemented Due to the complexities of this implementation compared to the perceived benefits, this feature will not be implemented at this stage

The topic of minor edits has come up several times primarily for reducing clutter in RecentChanges. My reason for continuing the discussion and wanting to follow up is related to my bliki

The way that BLiki runs at the moment is to order topics one the home page according to when they were last modified and it also features a calendar that shows the dates on which topics were last changed (like a blog). So, when I change a topic and update it then that topic comes back to top of the list and the calendar updates accordingly.

This is all well and good and behaves as expected. However, the other day I noticed a problem with some WikiTalk in a bunch of topics that needed changing, but didn't change the actual content or meaning of the topic and so it was what I would call a minor edit. If such a feature existed then my date-based processing could handle just the date of the last major edit and ignore minor edits, thus preserving the chronological flow of my topics.

What does this mean for everyone else? Well, adding a minor edits feature would certainly allow the RecentChanges for a topic to be shorter (by default), but by and large the overall impact to a FlexWiki user would be fairly minimal. From a WikiTalk developer perspective you would gain access to these dates allowing the kind of processing I described above to be implemented.

Affected Areas

The key area affected by the implementation of a minor edits feature will be the ContentBase and the actual editing of a topic. Essentially, this would need to be extended to allow an edit to marked as a minor edit. In more detail the FileSystemNamespaceProvider would need to cope with creating topic files, named appropriately to deal with minor edits. I'm not aware of any database NamespaceProviders, but I suspect that the implementation of minor edits for these if/when they do exist would be easier than for the FileSystemNamespaceProvider.

The WikiEdit.aspx is the area most visually affected as this would require some kind of check box to indicate whether this is a minor edit or not. Additionally, Versions.aspx would be enhanced visually to allow a user to show minor edits (working on the assumption that minor edits are hidden by default).

The FlexWikiWebService would also need to be updated to allow clients to submit and retrieve minor edits as well as including, if required, minor edits when retrieving the list of versions.

Issues

What's the risk? On a public wiki like FlexWiki I guess the risk is that no-one ever makes a minor edit, so perhaps you make the minor edit feature enabled by default, meaning that you specifically have to tick a box to say it's a major edit (except for topic creation which would always be a major edit), but then you run the risk of no-one ever making a major edit. To be honest I don't see this as a problem. People who are already wiki aware through experience with a different engine will most likely expect to see some kind of minor edit feature and use it accordingly; those who are new to wikis and starting with FlexWiki will 'grow up' with the feature and use it accordingly. The only problem section of users are the established FlexWiki users who are used to absence of a minor edit feature, so all we need to do there is educate them to its presence and how to use it.

Another area of worthy of discussion of that of backwards compatibility via the FlexWikiWebService. How do we cope with old clients connecting to new servers with minor edits and ''new clients connecting to old servers that don't have the minor edits feature? This issue has already been raised on FlexWikiWebService and is a general issue for the web service, rather than being specific to minor edits.

Questions Requiring Answers Before Implementation

Comments