Opasnet:Restructuring pyrkilo websites

From Opasnet
Jump to: navigation, search

Restructuring of pyrkilo websites describes the websites, their intended contents, and procedures to reach the contents in the pyrkilo.fi domain.

Purpose

The purpose of the website is to form a coherent and a large pool of material and methods for making assessments in the aim to help societal decision-making. The following objectives should be effectively solved:

  • People (including those that are not involved in any projects) should have easy access to openly available information and tools.
  • People that are involved in projects should be able to protect information they produce temporarily or permanently for specified reasons. The acceptable reasons should be decided upon.
  • The website system should be easily browsable.
  • It should always be clear what the best place is for a particular piece of information. This means both between the different sites, and within the page structure of a webite.
  • The structure of the website should be such that large structural changes are unlikely after the structure has been establised.
  • The structure should be compatible with the Intarese Guidance System, and when possible, be part of it.


Structure of process

Input format

Existing information that is relevant in this discussion is located in several pages, namely


Procedure

Basic structure

The following basic structure is suggested.

  • The Heande website should contain any freely available information that is or can be used in open assessments.
  • Another website, the project wiki site, should contain any infomation that is not freely available and is or can be used in open-like assessments that actually have restricted access for some reason. Each project should have an own project namespace for managerial issues.
    • This should be built on the existing Intarese site?
      #(1):: . The name is misleading and cannot be changed easily. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant attack)
      #(2):: . A lot of relevant stuff is there already, which minimises the need to move stuff. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant defense)
      #(3):: . There are management and ownership issues. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant attack)
    • This should be built on the existing pyrkilo site?
      #(1):: . The name is OK --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant defense)
      #(2):: . There are no ownership issues. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant defense)
      #(3):: . It contains only outdated stuff. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant attack)
    • This should be built on a new wiki site?
      #(1):: . We could give it a new fancy name. --Jouni 18:40, 12 April 2008 (EEST) (type: truth; paradigms: science: relevant defense)
  • A website (file management system?) should contain any information that is considered original data, whether or not it will be published at some point. What this FMS should be? Drupal? HSPH has done a lot of work on this, and we shoud consult them.
    • Could this be a data database (the sister of the result database?)
  • A website for variable results is needed. This currently exists and has th name ResultDB.

Transition procedure

The following procedure is suggested for the transition.

  • The project wiki site is opened as soon as the decision has been made.
  • All new projects will be hosted there.
  • Existing projects will stay where they are, but a plan is made for each: either they will have an own wiki permanently, or the currently relevant content is moved to the project wiki according to the plan.
  • In addition to project-level plan, a plan to go through each existing page will be made. The following things must be updated and straightened out.
    • The pages should end up to the right wiki (some may be ready to go to Heande?)
    • The pages should go the right namespace.
    • The pages should have at least one category, preferably several, and they must be used consistently across all wikis.
      • Methods should be categorised according to the guidebook structure.
      • Asssessments and variables should be categorised according to the full chain approach.
    • The strucure of each page should be according to the current method.
      • All variables should contain the template {{variable}}
      • The attributes must be the correct ones.


For editing pages, you can quickly make progress by using e.g. these approaces.

  • Look pages without categories from Special pages. Identify variables and add the variable template to all. Add guidebook template to all methods.
  • Look for Double redirects and correct them to direct to the current page.
  • Look through pages and add Release suggested template when you thing that the page should go to Heande.
  • Look through Release suggested category to se, if you can give the permission to release any pages.
  • Look through To be released category. Check that the release was actually accepted. Then move the page and the discussion page to Heande. Make a redirect. Make sure the links don't brake (or correct them).
  • Go through the Guidebook contents and identify pages that do not yet exist although they are listed. Make the page and categorise it to relevant categories, including Stub. It is not necessary to add substance, but if you can define the purpose of the page, it is very useful. If you find a non-released page that would fit here, make a link to that page (of course, only those that have the permission, will be able to follow the link)

Domains used

The new domain name will be opasnet.org. In addition, we will use opasnet.fi and opasnet.eu to redirect users to the actual site. The different wikis such as heande and tyjak will be moved under the new domain.

The currently used domains are

  • heande.pyrkilo.fi
  • tyjak.pyrkilo.fi
  • www.pyrkilo.fi/<project>

The new system should be flexible to show wikis for different purposes, such as different languages. Now, the prefixes en, fi, and so on refer to wikipedias in different languages. Open assessment wikis in different languages are referred to as heande, tyjak, and so on. The name itself does not tell the language, but they are abbreviations of translations from "Health, the Environment, and Everything" in that language. This seems practical. Also, we can think that open assessments are made for other purposes than environmental health, and there might be a future need to have websites for completely other topics.

What would be the name of the project website? It should reflect the fact that it can be for any project, it is a closed system, or something else?

  • Intra (too vague, everyone already has something they call intra)
  • project (same problems)
  • hands (for the idea that the "right hands" of every project work there)

In conclusion, the first part of the website name, before the domain should define the purpose and language of the project. This is used to refer to that website from within other projects.

Output

As a result, we will get rid of project-specific wiki sites. The management will become more easy, and the structure of the system guides both the developers and the users.

Rationale