Difference between revisions of "Save the KS Toolkit wiki"

From KM4Dev Wiki
Jump to: navigation, search
Line 19: Line 19:
  
 
== Ideas, suggestions and similar ==
 
== Ideas, suggestions and similar ==
=== Integrate KS Toolkit with KM4Dev wiki ===
 
Is that an option if KS Toolkit 'owning' organizations cannot foot the bill for an alternative Wiki platform?
 
 
(more details to be added to this idea: proponent, advantages, disadvantages and things that might get tricky)
 
 
 
=== Merge the KS Toolkit with the KM4Dev wiki ===
 
=== Merge the KS Toolkit with the KM4Dev wiki ===
 
We could re-create the toolkit as a section into this wiki. Similarly to how the Discussions and the People are handled on this wiki, there would be two additional "portals" on this wiki: one for "KS tools" and one for "[[Methods|KS Methods]]".
 
We could re-create the toolkit as a section into this wiki. Similarly to how the Discussions and the People are handled on this wiki, there would be two additional "portals" on this wiki: one for "KS tools" and one for "[[Methods|KS Methods]]".

Revision as of 15:06, 22 February 2018

This is the landing page to organize the work to be done to transfer and update the content of the KStoolkit.

Initiative started by Lucie mid February 2018

People interested in helping out

alphabetically by first name [suggestion: please add your Skype id behind your name if indeed you are on board and interested to work as a group]

Ideas, suggestions and similar

Merge the KS Toolkit with the KM4Dev wiki

We could re-create the toolkit as a section into this wiki. Similarly to how the Discussions and the People are handled on this wiki, there would be two additional "portals" on this wiki: one for "KS tools" and one for "KS Methods".

Tools and methods would be created and edited through user-friendly forms. Taking advantage of the semantic capabilities of this wiki, they would be categorized by "contexts" and "keywods" similarly (but more powerfully) to how they are currently categorized on the KS toolkit. For example (this example is focused on "ks methods"):

  • it would be possible to filter Methods by specific contexts and specific keywords simultaneously;
  • on a Method's page it would be possible to include links to relevant Tools and relevant Discussions;
  • members of KM4Dev who have a profile on this wiki and have contributed to preparing a method's page could be credited on the page with a link to their profile, where there would be links to other contributions of such members, such as discussions in which they participated

See a prototype for Methods:

Advantages:

  • This would allow us to have only one platform to maintain instead of two.
  • We gain semantic capabilities (already explained above)
  • We gain user-friendly forms, which makes it easier for non tech-savvy users to edit the toolkit

Disadvantages and things that might get tricky:

  • Migration is a manual process. It will take a lot of work to migrate 400+ pages including tools and methods. User-friendly forms and volunteer editors can help a great amount, however it might make sense to pay a consultant
  • This wiki has running costs and at the moment we don't have budget for fixing it if it breaks or if it needs an update

Proponent: Davide Piga

Rebuild the KS Toolkit using Google Apps

We could consider turning the toolkit into a Google Site where each tool and each method is documented on a Google Doc instead of a website page. We would lose tagging, but we would gain printable pages and easier maintenance.

At the basis of the toolkit there would be a Google Drive folder which would contain all tools and methods.

Suggested default permissions for the folder and the documents in itwould be "anybody with the link can comment", which means that anyone would be able to suggest changes by simply typing into the documents. Edits, before reflecting in the docs, would have to be approved by admins (just like the "track changes" function).

Proponent: Davide Piga

Advantages:

  1. if we need to migrate again, we can just embed the folder in some other website
  2. thanks to the fact that the toolkit is also a folder, it can be easily taken offline (toolkit on the go)
  3. each tool/method is a collaborative document
  4. it’s generally easier for users to add/edit tools/methods as they would just have to create and edit a google document (possibly starting from a standard template that we would provide to them) instead of editing a wiki (which requires knowledge of wiki syntax and an account on the wiki). Assumption: the vast majority of people have a Google account.

Disadvantages and things that might get tricky:

  1. Migration is a manual process. There are currently 400+ methods/tools on the toolkit. It will take some work, or some money (approximately 30 days for one consultant)