Publication process

There is an internal PBL wiki and an external wiki. The external wiki is a subset of the internal wiki and is meant to be viewed by webusers. The implementation will probably (discussion item) be by installing one wiki inside the firewall and one wiki outside the firewall. The external wiki will be filled by an import of pages from the internal wiki and periodically updated.

• Internal wiki: This wiki is visible for PBL employees and external people that can login (?). In principle all contentpages are visible for all these people. However there will be a difference between viewers, writers and administrators, with more options available in this sequence. Viewers can view and discuss; writers will have an extended menu with functions to add content and may edit pages; administrators can change the structure and maintain user rights and use other maintenance functions.
• External wiki: This is the publishable part of the internal wiki and will be accessible for the outside world via a PBL URL.

The Basics

• CurrentFrameworkVersion: this is the version number of the Wiki as a whole
• CurrentVersion: this is the version number of each page separately
• Approve-revisions-permission: this permission allows you to look at pages which are unaproved (and thus gives permission to the latest version of each page). This permission is only given to people who have a user-login. On default the setting $egApprovedRevsAutomaticApprovals is put on true. With this setting, each change will automatically be approved, and is thereby directly visible for external people. For some changes, you want to start the approval procedure. See the #How to handle changes section.

For more information about the approve-revision-permission, see [Approved Revs].

How to handle changes

There are several situations with different solutions:

1. Minor text change
   • May be a correction or enhancement: Enter the changes in the wiki.
   • No increasing CurrentVersion number and no approvement procedure
2. Small adaptations to model components, substantial rewriting of a description or new pages
   • Tekst aanpassen
   • Na eerste save; de huidige (werk)- versie via the history tab op ‘unaproved’zetten.
   • Alle volgende wijzigingen blijven dan unaproved
   • Doe dit voor de hele set van pagina’s die je moet wijzigen.
   • Wanneer alle wijzigingen binnen deze set klaar zijn:
     • Start approvement procedure:
     • Check de gebundelde gewijzigde componenten en losse pagina’s
     • Currentversion nummer ophogen per component (niet per pagina) waar je wijziging aanbrengt
     • Redactionele slag:
     • Editing & aprove status toepassen

• If a page has no approved revision (this of course includes new pages), automatic approvals will not be applied.
• Current version nummer eigenschap toevoegen
• Pakt bij de hij bij de overdracht de laatste versie of de ‘aproved’versie? Waarschijnlijk geen probleem want externe personen hebben geen RevisionApprovalPermission en zien de laatste versie dus niet?! (moet dan wel de laaste ‘aproved’versie zien/geen lege pagina)

1. Substantial change resulting in a new version: When making a substantial change to your model by adding a submodule or changing the conceptual model, ****

1. Nieuwe release:
   • Maak een archief versie ( evt. in html/pdf vorm, liefst pdf vorm want dan verwachten mensen niet dat de links werken) zie extenties: collection en pdfbook
   • De hele wiki op unaproved zetten ($egApprovedRevsAutomaticApprovals = false;)
   • Wijzigingen slechts op het eind allemaal tegelijk approven.