Feature #4140
closedDeprecate the wiki
100%
Description
During our last in-person meeting, the issue of the wiki - and its general lack of use - was raised. The idea was floated that we might consider deprecating the wiki altogether. I wanted to start a ticket for discussion of the advantages/disadvantages of getting rid of the wiki, and sketch what such a deprecation might look like from a technical point of view.
Reasons for keeping the wiki¶
a. The wiki has been part of the Commons from day one. It's a departure from tradition to get rid of it.
b. The wiki was meant to be a free-form, completely public place for people to collect information of interest to the community. Most other areas for content creation on the Commons are more locked down by various hierarchies. Docs, for example, are buried inside of groups. Sites are not easily tagged/organized to make them browseable. The wiki thus fills a conceptual gap in the site.
c. The wiki is home to a couple pieces of content that are regularly used. It powers the Help FAQ. The ePortfolios section is pretty nicely done. The Digital Humanities pages are fairly well known.
Reasons for ditching the wiki¶
a. The wiki is barely used and barely visited. Having a top-level site section with little to no activity doesn't reflect well on the vibrancy of the rest of the site.
b. Judging from the small amount of wiki activity, the role of the wiki in the Commons is not clear to users. This may be a case where taking away one possible form of content creation makes the remaining ones conceputally clearer.
c. The MediaWiki interface for reading (and especially for writing/editing) is much different from the other Commons interfaces, and I'd argue, much worse.
d. Maintaining MediaWiki alongside WordPress involves odd hacks (like our shared login and similar skins) that are difficult to maintain. Our MediaWiki instance hasn't been updated in years due to these hacks, and due to the fact that we have no MW expertise on our team.
What deprecation might look like¶
All of the arguments for getting rid of the wiki could be addressed by some other means. But, IMO, it's not worth the time and energy to do so, especially when we have so many ideas for how to improve the rest of the site. So let's assume for the moment that we get rid of the wiki. Here's how the deprecation might work in a minimally disruptive way:
1. Existing wiki content can be migrated to WordPress. We could use an existing system (like BuddyPress Docs) or write a standalone plugin. It should be possible to maintain the content as well as whatever proportion of wiki metadata (tags, etc) and history that we deem worthwhile.
2. We can write some code that will ensure that old wiki URLs will redirect to the new ones, so that content can still be found by Google and other incoming links.
3. Wiki links will be removed from top-level navigation. Migrated content will only be available by direct links (or, if we migrate into an existing system like Docs, by the regular Docs filter/search interfaces).
Thoughts and ideas are welcome. Even if we ultimately decide to keep the wiki, it's helpful to spell out our concerns in a forum like this.
Files
Related issues
Updated by Stephen Real over 9 years ago
I agree that the arguments for keeping the wiki can be addressed by other means, but can the reasons for keeping the wiki also be addressed by other means? Can we retain the valuable aspects namely the flexibility and the openness?
Would it make any sense to ask the community for input before we decide? I think the fact that the wiki is not well known is an important point. If it were well known, would it get more use? It might be interesting to construct a survey to surface the answer to that question.
Updated by Samantha Raddatz over 9 years ago
Thank you for outlining the reasoning and possible depreciation plan, Boone!
It's probably already known that I'm on the side of removing the wiki entirely, mostly due to its statistical lack of use. Also, the navigation real estate could be better used for other, newer features that we'd like to highlight -- like the events calendar, maybe.
I just went through my user testing notes and only have one instance of the wiki being discussed, by someone who noted that they had never noticed it before and weren't sure what it was for. That person brought it up in relation to a question concerning what they thought the distinction was between sites and blogs.
I'd be open to adding a specific question into the next round of testing for this if we'd like to get more input from users. While a survey could be helpful, I'm afraid that summer response rates might be low. I think a combination of the use statistics from Seth and in-person user feedback should sufficiently help us to make this decision.
Updated by Matt Gold about 9 years ago
- Status changed from New to Assigned
- Assignee set to Stephen Real
At the last few team and subcommittee meetings, we all agreed that we should deprecate and eventually remove the wiki. Let's use this ticket to organize that work.
To start, we will need to move selected content from the wiki -- like the CUNY Digital Humanities Resource Guide -- from the wiki to another space -- probably a blog.
We may want to contact creators of other content on the wiki to see whether they want our help in moving content.
We will also have to reframe our help workflow, since much of it is based on the wiki FAQs.
Updated by Boone Gorges almost 9 years ago
- Target version changed from Future release to 1.10
Updated by Stephen Real almost 9 years ago
- File wiki sunset plan.xlsx wiki sunset plan.xlsx added
I am attaching an Excel spreadsheet that contains a draft list of tasks for deprecating the wiki. I can add dates after we agree on the tasks. I am going to close the the ticket that duplicates this effort.
Updated by Matt Gold almost 9 years ago
Thanks for moving forward on this, Stephen! Perhaps you and Boone (with Scott, if he can) can set up a call to work through this list.
Updated by scott voth almost 9 years ago
Hi Steve - one other thing to remember is that the Commons FAQ page is still on the wiki. We should probably see if the plugin we have on the Commons is good enough to use, and make plans to migrate the content to WP.
Updated by Boone Gorges almost 9 years ago
- File wiki-documents.csv wiki-documents.csv added
- Assignee changed from Stephen Real to scott voth
The attachment wiki-documents.csv contains a list of Wiki pages, along with some info about them: date created, info about creator, date last edited, info about last editor, revision count. I've tried to edit out the noise (eg, file uploads and auto-generated Categories) but there may still be some in there. Scott, can you spend a few minutes with the document to see how it looks to you? If I can provide more info that would be helpful, I'm happy to do so.
Updated by scott voth almost 9 years ago
Hi Boone - I spent some time looking these over. The list seems also to contain category links - so there are probably 100 or so less pages that the spreadsheet indicates, but still quite a number. I did some research about export/import from Media Wiki to WordPress - but came to a dead end on that idea.
But then I found a company that will migrate our whole wiki site to WordPress for $58.35. I did a demo - and the results look great EXCEPT they only did the titles. I wrote to them to see if they can provide an example of what the content would look like. Can you check this out and see what you think? https://www.cms2cms.com/ It seems like (if it works) it would simplify this task greatly. I think you would still be able to create the redirects from old URLs?
Updated by Boone Gorges almost 9 years ago
- Assignee changed from scott voth to Boone Gorges
Thank you for having a look, Scott.
Based on your comment - "quite a number" - I'm assuming you think we should do both of the following:
(a) move everything first, and contact people about the move afterward (instead of contacting them first to find out whether they'd like things moved - there are too many pages for this)
(b) move things in an automated fashion, since it's a large amount of content (we'd discussed the possibility of doing it manually)
Is this correct?
Thanks also for the research regarding cms2cms. I've seen this service before. To be honest, I don't know that I trust this kind of thing to a service. Not that they don't do a good job - they probably do - but I want to be sure that things are moved over in a way that's sensitive to our server environment, our redirect requirements, etc. Since I've already written the code to create a list of extant wiki pages, most of the work is actually done. It's only a small task at this point to loop through them all, make an HTTP request for each, parse out the page content, and then convert it to a WordPress page.
I'll work this week on writing this tool. Maybe I can get it up and running on cdev, so that we can begin testing. I'm assigning the ticket to myself as I work on this.
On a related note. Scott, do you have any suggestions for what the new WP-based wiki site should look like? Any themes you have in mind - either existing on the Commons, or something we could install fresh? Would it be best to go with something simple, like a theme based on Twenty Sixteen? Should we try to make it look kinda-sorta like the old wiki?
Updated by Boone Gorges almost 9 years ago
Hi all -
I have run an initial import of our wiki content into a Commons site. http://commons.gc.cuny.edu Stephen and Scott, you are both admins on the site. If anyone else wants access while we're working, let me know and I will add you.
Here's an example of a page: http://wiki.commons.gc.cuny.edu/omeka_basics/ All existing pages are available - translate URLs of the form
http://commons.gc.cuny.edu/wiki/index.php/THIS_IS_THE_PAGE_TITLE
to
http://wiki.commons.gc.cuny.edu/THIS_IS_THE_PAGE_TITLE
You'll see that I've pulled over images. Unfortunately, these images continue to be hyperlinks, and they're all broken. I'll try to fix this.
Tables of contents work, though could possibly use some styling work.
I've preserved the author information, date created, and last edited date. See eg https://wiki.commons.gc.cuny.edu/wp-admin/edit.php?post_type=page&paged=2. This data is not displayed anywhere on the frontend. Suggestions welcome.
Scott, you mentioned that there were some category pages in the initial export. I see that there were also some media-specific pages, which don't have any content. If you can identify any naming patterns that would help me to sift through these items programatically, please let me know.
I've got more work to do here, but I wanted to get this in your hands so you could start thinking about what the content might look like in a WP context.
Updated by Matt Gold almost 9 years ago
Wow -- fantastic progress, all. Thanks so much.
Updated by scott voth almost 9 years ago
This is really cool! Not to get greedy - but it would be great if we can figure out how to import the categories. The category pages we can probably skip, since WP does a pretty good job of displaying pages in a category (I think it needs a plugin though). I did not see any naming pattern difference between the category pages and regular pages, and it was confusing to me initially. Then I realized they were the same as what the category (i.e. tag) cloud pulls. Would that help you? There are also sub categories - to add to the challenge.
I like the simplicity of the theme in 2012 - good to start there. I can look for other wiki-like themes - but they might imply that this is an active wiki - but I wonder if it might be possible to make the site somewhat dynamic by a button for members to request edit permissions, and keep the site alive?
Great work!
Updated by Boone Gorges almost 9 years ago
- Assignee changed from Boone Gorges to scott voth
Thanks for having a look, Scott!
I neglected to move the categories first time around - whoops. I just did a re-import that parsed out and added them as appropriate.
From what I could see, there was no easy way to gauge based on the wiki page output whether a category was nested (subcategories). So currently the hierarchy is flat. My suggestion is that we manually fix the hierarchies - it can only be a few dozen categories.
Scott, can I ask you to look into the following tasks, as next steps?
1. Review the Categories, and reorganize in hierarchy as needed https://wiki.commons.gc.cuny.edu/wp-admin/edit-tags.php?taxonomy=category&post_type=page
2. Identify and delete any obvious test pages, category pages, and other stuff that shouldn't be there https://wiki.commons.gc.cuny.edu/wp-admin/edit.php?post_type=page I think you can probably see just by looking over the titles that some of the pages are sandboxes, etc, and should be sent to the trash
3. Make some concrete suggestions about how to modify the existing Twenty Twelve theme about how to make it display the content better. For example, the categories are not currently displayed anywhere (because they're technically Pages, and Twenty Twelve doesn't put categories in the page template). Where would they go? What would you like to see in the sidebar (feel free to make those changes yourself)? Anything we can do with color schemes, branding, etc to make it integrate better with the rest of the site? Maybe something like what you've done with the Codex?
Regarding "active" wiki - I would say that we do not want to have a public way for people to request access in an automated way, but it's a good idea to have something somewhere on the page - maybe an About page, or maybe in the footer - that explains how the site holds all the content migrated from MediaWiki, and gives info about how to get in touch with the team to edit/remove content.
Updated by Stephen Real over 8 years ago
Scott,
Please check out Boone's latest update on this ticket. If you have done the things he asked, I think we are just about done. Once these items are done, we need to do the following in a coordinated "deployment."
1) Create a hero slide and news post that the Wiki is no more, explaining the details
2) Remove the Wiki tab and add the Events Calendar tab
Updated by Boone Gorges over 8 years ago
- Assignee changed from scott voth to Stephen Real
Excited to move forward with this. As noted on yesterday's call, it's in the 2.0 milestone, but we can make the move sooner if we are ready.
Have we decided on the publicity that will surround this move? Two possible categories:
1. An email to content owners to let them know that we've moved stuff. I imagine it'd take the form: Here's what we've done; here's why; here's what's happened to your stuff (maybe personalized? though this might be too difficult); here's what you need to do (mostly nothing, unless you have content you want edited or removed, in which case we can add you to the site as an Author). Someone will need to draft this. I can pull a list of email addresses.
2. More general publicity - hero slide, news post, etc. This is what Steve suggests above. I'm not sure that this is really necessary, but it's a nice way to document the process - we could frame the post as a narrative of how use of the Commons has changed over time, and how we try to respond to it. I think this is optional, and doesn't have to correspond with the migration itself.
It's possible that we do only one of these. I don't really have a preference.
Technical steps:
a. .htaccess redirects. This should include single posts and category posts.
b. Category name translation (underscores to hyphens. WP handles this for post slugs, but not for category slugs)
I've written code that handles both a and b: https://github.com/cuny-academic-commons/cac/commit/eab48bde8d7a477e3d24c9ddbb07eab9dc8b9031
As Steve notes above, the final step at launch will be to change the Wiki tab to Events, which will point to commons.gc.cuny.edu/events/.
I think we just need some decisions about publicity, and then we can schedule the move. Assigning to Steve to handle the coordination - once we're ready, hot-potato it back to me.
Updated by Stephen Real over 8 years ago
Do we have the email addresses of all the content owners? If so, I think we should send them a notification as a courtesy. Once I know that we have the addresses, I can draft the message.
I like the idea of a news post nominally about the demise of the wiki, but including some useful tips and/or narrative about the evolution of the Commons. I will see if I can't get that in the hopper, as well.
Updated by Boone Gorges over 8 years ago
Yes, I will be able to pull the email address list, if we decide it's something we want to do.
Updated by Boone Gorges over 8 years ago
We're drafting an email notice to content authors at http://commons.gc.cuny.edu/groups/cac-community-team-project-planning/docs/email-notice-to-owners-of-wiki-content/
Updated by Boone Gorges over 8 years ago
I believe this technical parts of the work are done. A couple clean-up tasks as I deployed the changes:
- Use 301 rather than 302 redirects (302 was for testing) https://github.com/cuny-academic-commons/cac/commit/47b373fe7a3927bccf9a79633cd7406ded2c48b3
- Don't run the MW logout routine on WP logout https://github.com/cuny-academic-commons/cac/commit/b56b742ed5a95c8f868aca6739271d3ba879b1c6
- Change 'Wiki' to 'Events' on the upper-left "CUNY Academic Commons" toolbar dropdown https://github.com/cuny-academic-commons/cac/commit/cee407bd6a6dc1d661a19997d760607540b07067
The change from 'Wiki' to 'Events' on the main site nav was made in the database. Developers: to make your installations match, go to Dashboard > Appearance > Menus and change the Wiki custom link to Events with the proper URL. I've made this change on the production site as well as cdev.
Stephen, Sarah - I think we're ready to pull the trigger on any remaining publicity.
Updated by Boone Gorges over 8 years ago
- Status changed from Assigned to Resolved
Thanks, Sarah!
I think we are done here. I'll keep the wiki database and codebase in place for the time being, in case we discover anything that hasn't been migrated properly. At some point in the future, these things can be cleaned up. If anyone notices glitches in the migrated content, please open a separate ticket.