Difference between revisions of "Save the KS Toolkit wiki"

Revision as of 10:25, 28 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. NOTE: this is not to suggest that Skype would be the collab platform, it is just meant to get in touch quickly and agree on something. Our [1]coordination Skype group is here]

• Arwen Bailey
• Carl Jackson - Skype: carl_wkg
• Davide Piga
• Johannes Schunter
• Lucie Lamoureux - Skype: lucielamour
• Nadejda Loumbeva
• Nadia von Holtzen
• Nancy White (prefer Slack) < Peter: Nancy read my suggestion on top!
• Pete Cranston
• Peter J. Bury - Skype: profbury
• Sophie Alvarez
• Simone Staiger - simonestaiger

Ideas, suggestions and similar

Merge the KS Toolkit with the KM4Dev wiki

We could re-create the toolkit as a section of this wiki. Similarly to the Discussions and the Members sections, there would be two additional "portals": 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 to (but more powerfully than) the way 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:

• Full list of Methods - methods portal
• Methods advanced search - filter methods by multiple categories
• Sample method - click on "Edit with form" to also see the user-friendly form

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 for 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.

• See a prototype

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

• See the folder

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)

Merge With Existing Toolkits

From Michael Hill When I look at the KS Toolkit, it looks like there is much overlap with: http://www.click4it.org/index.php/Toolkits which is part of UNITAR's (United Nation Institute for Training and Research) Learning and Training (and KM) wiki. Perhaps rather than rebuilding you can link to what they've already done, and eventually seek a partnership with their KM folks. Their KM repository is even bigger than the toolkit. You can go to the repository by clicking on the KM link on the menu bar toward the top right of the Toolkit page.

We considered building something like UNITAR's page, after we found it we just point our students there instead.

Feature Ideas

• From Tina: For changes:

- it would be great to have an easy way in the future to differentiate languages (other than english), in my case spanish. - it would be great to have a living "organizational support page". There are two types of supporters: the big ones caring about the whole thing, smaller supporters (km for dev. staff/we and organizations). Space and visibility for the second type = may be more content support within our formal working plans.

• From Krishan (see the larger email) The point is to pick up on how well the KS Toolkit reflects the nature and identity of the Community; I interpret it as ‘How does the Toolkit reflect the different processes we are implementing or the purposes we are addressing’ in KM4Dev. Perhaps an approach to the analysis we did may be a useful way to re-organise the KS Toolkit as we deal with the transfer of 400+ pages reflecting around 180 M&T.

Questions

• Do we need to port over all the old discussions attached to wiki pages. This is more work. (NW - I don't see value in preserving discussions, CJ agree)
• Do we need to carry over all old revision history for wiki pages. Again more work (CJ - agree with NW not much value in that)
• Do we prune the Tools section out all together? (CJ seems like we loose something so no)
• Do we improve pages during the transition (check links, create new crosslinks to new index, work to improve language stuff? - CJ optional page by page)
• Who registered and pays for the http://www.kstoolkit.org url? (I think we should preserve this and use redirects at the least, if not host the new wiki AT this url - NW)