Zib afspraken - Bewerkingsoverzicht

Albert-Jan Spruyt: /* Verwerken nieuw versienummer */

2020-12-24T01:07:55Z

Verwerken nieuw versienummer

← Oudere versie		Versie van 24 dec 2020 03:07
Regel 486:		Regel 486:
	*bestandsnaam van het voorbeeldbestand.		*bestandsnaam van het voorbeeldbestand.

	Daarnaast moet de DCM::~~Superseeds~~ tag aangepast worden.		Daarnaast moet de DCM::Supersedes tag aangepast worden.

	===Verwerken issues===		===Verwerken issues===

Albert-Jan Spruyt: /* Verwerken issues */

2020-07-27T20:18:49Z

Verwerken issues

← Oudere versie		Versie van 27 jul 2020 22:18
Regel 509:		Regel 509:
	*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)		*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)
	*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.		*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.
	* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een publicatie te hebben gezeten [[mogen]] ze bij de volgende publicatie worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde' bij datatype CO. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.		* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na één maal in een publicatie te hebben gezeten [[mogen]] ze bij de volgende publicatie worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde' bij datatype CO. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.
	* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.		* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.
	*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).		*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).
	*In Bits'' Verdeel als administrator -indien mogelijk- alle wijzingen op 1 zib aan dezelfde modelleur.		*In Bits'' Verdeel als administrator -indien mogelijk- alle wijzingen op één zib aan dezelfde modelleur.
	*'''In Bits''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".		*'''In Bits''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".
	*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal ~~1 x~~ na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)		*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal één keer na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)
	*'''In Bits''' wijzig de administrator de status dan zoals afgesproken naar 'in realisatie'. Indien nodig vraag via comment @gebruikersnaamBits aan de administrator dit te doen.		*'''In Bits''' wijzig de administrator de status dan zoals afgesproken naar 'in realisatie'. Indien nodig vraag via comment @gebruikersnaamBits aan de administrator dit te doen.

Albert-Jan Spruyt: /* Verwerken issues */

2020-07-27T13:33:25Z

Verwerken issues

← Oudere versie		Versie van 27 jul 2020 15:33
Regel 509:		Regel 509:
	*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)		*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)
	*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.		*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.
	* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een ~~release~~ te hebben gezeten [[mogen]] ze bij de volgende ~~release~~ worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde' bij datatype CO. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.		* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een publicatie te hebben gezeten [[mogen]] ze bij de volgende publicatie worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde' bij datatype CO. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.
	* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.		* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.
	*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).		*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).

Linda Mook: /* Verwerken issues */

2020-05-20T07:29:09Z

Verwerken issues

← Oudere versie		Versie van 20 mei 2020 09:29
Regel 509:		Regel 509:
	*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)		*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)
	*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.		*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.
	* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een release te hebben gezeten [[mogen]] ze bij de volgende release worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde'. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.		* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een release te hebben gezeten [[mogen]] ze bij de volgende release worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde' bij datatype CO. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.
	* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.		* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.
	*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).		*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).

Linda Mook: /* Verwerken issues */

2020-05-20T07:27:34Z

Verwerken issues

← Oudere versie		Versie van 20 mei 2020 09:27
Regel 509:		Regel 509:
	*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)		*'''In EA''' voeg tijdens de eerste wijziging aan een zib voor een (pre)publicatie de datum niet in maar zet er (nn-nn-nnnn achter). Dit wordt tijdens de daadwerkelijke (pre)publicatie gedaan waarna voor alle gewijzigde zibs de datum gelijk wordt gezet. vb. Publicatieversie 3.3.1 (nn-nn-nnnn)
	*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.		*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.
			* '''In EA''' bij het aanpassen en wijzigen van waarden in een codelijst zet de uit te faseren waarden op DEPRECATED en voeg de nieuwe toe als een rij in de tabel. T.b.v backward compatibility [[moeten]] DEPRECATED items altijd in opvolgende pre-publicaties blijven bestaan. Na 1 maal in een release te hebben gezeten [[mogen]] ze bij de volgende release worden verwijderd (maak hier wel een wijzigingsverzoek voor aan). Dit is ook van toepassing bij het toevoegen van bijvoorbeeld SNOMED CT term bij 'code' als voor wijzigingen in de 'concept waarde'. Een uitzondering hierop is een echte 'spelfout' of typo in een omschrijving. Deze mogen wel zonder deze regel aangepast worden.
			* Bij het doorvoeren van elke wijzing bekijk hoe deze indien mogelijk forward en backward compatible zijn. '''Backward compatible''' is een informatiemodel dat compatibel is met eerdere versies van zichzelf. '''Forward compatible''' is een informatiemodel dat compatibel is met toekomstige versies van zichzelf.
	*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).		*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).
	*~~I'''n~~ Bits'' Verdeel als administrator -indien mogelijk- alle wijzingen op 1 zib aan dezelfde modelleur.		*In Bits'' Verdeel als administrator -indien mogelijk- alle wijzingen op 1 zib aan dezelfde modelleur.
	*'''In Bits''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".		*'''In Bits''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".
	*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)		*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)
	*'''In Bits''' ~~als de modelleur~~ de ~~admin rechten heeft, wijzig~~ de status dan zoals afgesproken naar 'in realisatie' of vraag via ~~een~~ comment @~~naamVanEenAdministrator~~ dit te doen.		*'''In Bits''' wijzig de administrator de status dan zoals afgesproken naar 'in realisatie'. Indien nodig vraag via comment @gebruikersnaamBits aan de administrator dit te doen.

Linda Mook: /* Examples Instances */

2020-05-20T07:09:06Z

Examples Instances

← Oudere versie		Versie van 20 mei 2020 09:09
Regel 440:		Regel 440:
	De sectie bevat een in Word gemaakt integraal voorbeeld van de waarden die de elementen van de zib kan bevatten.<br>		De sectie bevat een in Word gemaakt integraal voorbeeld van de waarden die de elementen van de zib kan bevatten.<br>
	Het voorbeeld moet realistisch en illustratief zijn maar hoeft niet alle elementen van de zib te bevatten.<br>		Het voorbeeld moet realistisch en illustratief zijn maar hoeft niet alle elementen van de zib te bevatten.<br>
	Om het voorbeeld te plaatsen, wordt ~~aan~~ de ~~sectie een diagram toegevoegd van het type ‘ Custom’~~.~~<br>~~		Om het voorbeeld te plaatsen, wordt het door het zib centrum in de map 'voorbeelden' bij de juiste EAP file geplaatst. (Het wordt niet langer in de EAP file gepaste als PNG file).<br>.
	~~In dit diagram~~ wordt ~~het voorbeeld~~ als ~~png image geplaatst (paste from clipboard~~).<br>		Het Word bestand met het voorbeeld krijgt bij elke wijzing van de zib een nieuw volgnummer gelijk aan het versienummer van zib.<br>
	Het Word bestand met het voorbeeld ~~wordt separaat opgeslagen t.b.v. volgende versies~~.<br>
	=Afspraken over het maken van nieuwe zibs en nieuwe versies van bestaande zibs=		=Afspraken over het maken van nieuwe zibs en nieuwe versies van bestaande zibs=
	Het maken van nieuwe zibs wordt gedaan in een test EA project file. Dit kan een kopie zijn van de officiele zib EA project file of een andere aan de [[Opzetten_EA_omgeving \| eisen]] voldoende file.<br>		Het maken van nieuwe zibs wordt gedaan in een test EA project file. Dit kan een kopie zijn van de officiele zib EA project file of een andere aan de [[Opzetten_EA_omgeving \| eisen]] voldoende file.<br>

Albert-Jan Spruyt: /* Verwerken issues */

2020-05-19T20:19:48Z

Verwerken issues

← Oudere versie		Versie van 19 mei 2020 22:19
Regel 514:		Regel 514:
	*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)		*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)
	*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.		*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.
	Tenslotte, maak zoveel als mogelijk gebruik van de '''EA Add-in''' voor het doorvoeren van wijzingen aan de items ''maar hou er rekening mee dat niet alle mogelijke wijzingen hierin mogelijk zijn en ook niet alle mogelijke fouten gedurende het release proces worden gevonden''.

Linda Mook: /* Verwerken issues */

2020-05-19T13:53:37Z

Verwerken issues

← Oudere versie		Versie van 19 mei 2020 15:53
Regel 514:		Regel 514:
	*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)		*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)
	*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.		*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.
			Tenslotte, maak zoveel als mogelijk gebruik van de '''EA Add-in''' voor het doorvoeren van wijzingen aan de items ''maar hou er rekening mee dat niet alle mogelijke wijzingen hierin mogelijk zijn en ook niet alle mogelijke fouten gedurende het release proces worden gevonden''.

Linda Mook: /* Vaststellen nieuw versienummer */

2020-05-19T13:49:24Z

Vaststellen nieuw versienummer

← Oudere versie		Versie van 19 mei 2020 15:49
Regel 472:		Regel 472:
	Bij het ophogen van het versienummer worden de volgende regels gehanteerd:		Bij het ophogen van het versienummer worden de volgende regels gehanteerd:
	*ophogen sub-sub-nummer (A&B):		*ophogen sub-sub-nummer (A&B):
	:correcties, wijzigingen en kleine aanvullingen van sectie of definitie teksten met geen of minimale impact op de compatibiliteit, b.v. toevoeging SNOMED CT code als deze ontbrak. A is alleen voor het aanpassen van typo's die we tegen komen en meenemen. Formeel hoeven deze niet langs consultatie en autorisatie maar worden wel als wijzing meegenomen.		:correcties, wijzigingen en kleine aanvullingen van sectie of definitie teksten met geen of minimale impact op de compatibiliteit, b.v. toevoeging SNOMED CT of andere code als deze ontbrak. A is alleen voor het aanpassen van typo's die we tegen komen en meenemen. Formeel hoeven deze niet langs consultatie en autorisatie maar worden wel als wijzing meegenomen.
	*ophogen sub-nummer (C)		*ophogen sub-nummer (C)
	:correcties, wijzigingen, toevoegingen, verwijderen van elementen en wijziging van ~~terminologie binding~~ codes en wijziging van inhoud van waardenlijsten,		:correcties, wijzigingen, toevoegingen, verwijderen van elementen en wijziging van SNOMED CT of andere codes en wijziging van inhoud van waardenlijsten,
	:grote inhoudelijke wijzigingen van concepten en purpose teksten,		:grote inhoudelijke wijzigingen van concepten en purpose teksten,
	*ophogen hoofd versienummer (D):		*ophogen hoofd versienummer (D):

Linda Mook: /* Verwerken issues */

2020-05-19T13:47:46Z

Verwerken issues

← Oudere versie		Versie van 19 mei 2020 15:47
Regel 510:		Regel 510:
	*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.		*'''In Bits''' check de categorie van de wijziging (B,C of D) en pas aan mocht dit niet kloppen.
	*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).		*Verwerk '''in EA''' -indien mogelijk- alle wijzigingen per zib (ivm eenmalig aanpassen versienummer en voorbeeld). ( TIP Sorteer '''in bits''' alle wijzigsverzoeken per bouwsteen zodat je weet welke er op staan).
	*I'''n ~~Bit~~'''s Verdeel als administrator -indien mogelijk- alle wijzingen op 1 zib aan dezelfde modelleur.		*I'''n Bits'' Verdeel als administrator -indien mogelijk- alle wijzingen op 1 zib aan dezelfde modelleur.
	*'''In ~~bits~~''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".		*'''In Bits''' voeg een commentaar toe bij het issue "wijzing in EA doorgevoerd".
	*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)		*'''In EA''' run het Testreport via de '''EA Add-in''' minimaal 1 x na het maken van alle aanpassingen (dit spaart tijd aan het eind bij de publicatie)
	*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.		*'''In Bits''' als de modelleur de admin rechten heeft, wijzig de status dan zoals afgesproken naar 'in realisatie' of vraag via een comment @naamVanEenAdministrator dit te doen.