Use cases 2015 - Bewerkingsoverzicht

Rrr op 16 aug 2025 om 09:17

2025-08-16T09:17:43Z

Rrr: Rrr heeft de pagina Use cases hernoemd naar Use cases 2015 zonder een doorverwijzing achter te laten: new site

2025-08-16T09:16:31Z

Rrr heeft de pagina Use cases hernoemd naar Use cases 2015 zonder een doorverwijzing achter te laten: new site

Rrr: /* System hands over petition */

2015-12-04T13:58:49Z

‎System hands over petition

Rrr: /* System hands over petition */

2015-12-03T11:25:05Z

‎System hands over petition

Rrr: /* System hands over petition */

2015-12-03T11:23:19Z

‎System hands over petition

Rrr: /* User hands over petition */

2015-11-30T15:28:14Z

‎User hands over petition

Rrr: /* User adopts a petition */

2015-10-24T23:29:36Z

‎User adopts a petition

Rrr: /* User moderates a petition */

2015-10-24T23:13:45Z

‎User moderates a petition

Rrr: /* User moderates a petition */

2015-10-24T23:12:19Z

‎User moderates a petition

Rrr: /* User manages/improves petition */

2015-10-24T22:58:03Z

‎User manages/improves petition

@@ Regel 3: / Regel 3: @@
 At any of these stages the user might need help or want information about what the site is about, who is behind it etc. Can be found in the footer.
-These use cases required the following [[screens]].
+These use cases required the following [[screens 2015]].
 The system sends out these [[e-mailmessages]] which are numbered in these use cases.

@@ Regel 144: / Regel 144: @@
 == System hands over petition ==
-* petition status changes '''to_process''' a week before the actual hand over, petition remains signable. E-mail [[e-mailmessages|(18)]] to user and admin. When petitioner scheduled the date for the handover within a week after publishing the petition, or without (m)any signatures then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does cause and a loop with endless messages.
+* petition status changes '''to_process''' a week before the actual hand over, petition remains signable. E-mail [[e-mailmessages|(18)]] to user and admin. When petitioner scheduled the date for the handover within a week after publishing the petition, or without (m)any signatures then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does not cause a loop with endless messages.
-* User is asked by e-mail [[e-mailmessages|(18)]] to write an update about the pending hand over (when and where) with the information received from the addressee about it which will appear under the petition. And call addressee when they did not call.
+* User is asked by e-mail [[e-mailmessages|(18)]] to write an update about the pending hand over (when and where) with the information received from the addressee. The update will appear under the petition. And a reminder to call the addressee when they did not call.
 * e-mail [[e-mailmessages|(23)]] with petition and stats about signatures (not the signatures) goes to addressee (cc to admin), including suggestion to join us and open a free account, sent from subdomain@ourdomain with the name of petitioner in From-line.
 * when addressee clicks on link in e-mail as petition desk [[e-mailmessages|(23)]] they can (only!) change the date for the hand over and add a unique identifier the petition got in their own (postal) system. When they reply by e-mail the admin and/or user does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.

@@ Regel 148: / Regel 148: @@
 * User is asked by e-mail [[e-mailmessages|(18)]] to write an update about the pending hand over (when and where) with the information received from the addressee about it which will appear under the petition. And call addressee when they did not call.
 * e-mail [[e-mailmessages|(23)]] with petition and stats about signatures (not the signatures) goes to addressee (cc to admin), including suggestion to join us and open a free account, sent from subdomain@ourdomain with the name of petitioner in From-line.
-* when addressee clicks on link in e-mail [[e-mailmessages|(23)]] they can (only!) change the date for the hand over and add a unique identifier the petition got in their own (postal) system. When they reply by e-mail the admin and/or user does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.
+* when addressee clicks on link in e-mail as petition desk [[e-mailmessages|(23)]] they can (only!) change the date for the hand over and add a unique identifier the petition got in their own (postal) system. When they reply by e-mail the admin and/or user does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.
 * when addressee does not reply, the hand over date is prolonged with a week and a reminder e-mail [[e-mailmessages|(24)]] is sent. After four reminders the petition closes automatically and a 'virtual' hand over takes place, a PDF by e-mail [[e-mailmessages|(25)]] and the status closes to '''in_process''', as below.
 * The petition and list of signatures goes out by [[e-mailmessages|(25)]] on the day of the hand over as PDF, the petition closes and the status changes to '''in_process'''. The closed petition will show a time stamp of the hand over, the status 'in process' and 'awaiting due date for answer'. Also it says that the process of the petition will be monitored and that the next steps will be: indication on how petition will be treated, date of answer to petition, plus the answer.

@@ Regel 145: / Regel 145: @@
 == System hands over petition ==
-* petition status changes '''to_process''' a week before the actual hand over, petition remains signable. E-mail [[e-mailmessages|(18)]] to user and admin. When petitioner tries to do it without (m)any signatures and/or within a week after publishing the petition, then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does cause and a loop with endless messages. User is asked by e-mail [[e-mailmessages|(18)]] to write an update about the pending hand over (when and where) with the information received from the addressee about it which will appear under the petition. And call addressee when they did not call.
+* petition status changes '''to_process''' a week before the actual hand over, petition remains signable. E-mail [[e-mailmessages|(18)]] to user and admin. When petitioner scheduled the date for the handover within a week after publishing the petition, or without (m)any signatures then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does cause and a loop with endless messages.
 * e-mail [[e-mailmessages|(23)]] with petition and stats about signatures (not the signatures) goes to addressee (cc to admin), including suggestion to join us and open a free account, sent from subdomain@ourdomain with the name of petitioner in From-line.
 * when addressee clicks on link in e-mail [[e-mailmessages|(23)]] they can (only!) change the date for the hand over and add a unique identifier the petition got in their own (postal) system. When they reply by e-mail the admin and/or user does this manually. Addressee is asked to call + e-mail petitioner to explain the hand over process and such formalities.

@@ Regel 143: / Regel 143: @@
 * petitioner communicates with signatories who indicated they are open for this, they ask admin for help. In ''Future release'' a messaging system and archive of messages between petitioner and signatory. Only signatories can reach petitioner.
-== User hands over petition ==
+== System hands over petition ==
 * petition status changes '''to_process''' a week before the actual hand over, petition remains signable. E-mail [[e-mailmessages|(18)]] to user and admin. When petitioner tries to do it without (m)any signatures and/or within a week after publishing the petition, then status does not change and only admin receives a message and admin contacts signatory (fix this or confirm that it was your intention). Make sure that a hand over date in the past does cause and a loop with endless messages. User is asked by e-mail [[e-mailmessages|(18)]] to write an update about the pending hand over (when and where) with the information received from the addressee about it which will appear under the petition. And call addressee when they did not call.

← Oudere versie	Versie van 16 aug 2025 om 09:16
(geen verschil)

@@ Regel 161: / Regel 161: @@
 == User adopts a petition ==
-* petitioner does not reply to the e-mail that hand over date is approaching
+* petitioner does not log in ever
-* petition status changes to new status 'orphaned' which will show in the 'details' of the petition, will remain signable though
+* petition status changes a week before hand over date to new status 'orphaned' which will show in the 'details' of the petition, will remain signable though
-* oldest signatory is asked by e-mail to adopt the orphaned petition
+* oldest signatory is asked by e-mail [[e-mailmessages|(31)]] to adopt the orphaned petition
 * when signatory declines to adopt, then next oldest signatory is asked to adopt (we asked x others before you, they gave as a reason to decline...)
 * this repeats until all have been approached, then petition status automatically goes to 'withdrawn'
@@ Regel 174: / Regel 174: @@
 # can't adopt the petition for personal reasons (too busy, not my thing)
 # other...
-* the reasons to decline adoption can always be changed and also when the e-mail was not received
+* when signatory does not respond, after a day the next one is asked
 * when petition closes and goes to 'withdrawn', then the results of the above survey is published next to the petition
-* e-mail goes to all signatories when a petition is not adopted and withdrawn, survey results included.  In that message also the assurance that all irrelevant personal data will be deleted and that signatures set to anonymous will be completely deleted. That they can donate to us, subscribe to the newsletter, follow new petitions appear on twitter, etc.
+* e-mail [[e-mailmessages|(32)]] goes to all signatories when a petition is not adopted and withdrawn, survey results included.  In that message also the assurance that all irrelevant personal data will be deleted and that signatures set to anonymous will be completely deleted. That they can donate to us, subscribe to the newsletter, follow new petitions appear on twitter, etc.
-* to adopt a petition, a link 'I adopt this petition' can be chosen on the confirmation page. When a new quest for adoption starts, it starts with the signatory after the last to adopt the petition.
+* to adopt a petition, a link 'I adopt this petition' can be chosen on the confirmation page. When a new quest for adoption starts, it starts with the signatory after the last one asked to adopt the petition.
 == User moderates a petition ==

@@ Regel 182: / Regel 182: @@
 * petitioner starts a petition, confirms petition (by following link sent by e-mail) and then works on draft petition
-* moderator receives e-mail [[e-mailmessages (27)]] alert about this 'intention of a petition' and can already e-mail or call the petitioner to assist
+* moderator receives e-mail [[e-mailmessages|(27)]] alert about this 'intention of a petition' and can already e-mail or call the petitioner to assist
-* petitioner indicates that the petition is ready for publication, moderator receives e-mail [[e-mailmessages (28)]] alert
+* petitioner indicates that the petition is ready for publication, moderator receives e-mail [[e-mailmessages|(28)]] alert
 user is moderating on behalf of an addressee of petitions (like a city, a province) or is one of us, only gets to see petitions attached to that city/province through their 'office' (one office can be about more places)
@@ Regel 190: / Regel 190: @@
 * when userID+password gives error, a password reset can be requested online
 * moderator logs in and gets overview of status for only petitions that belong to her 'office'
-* moderator corrects the addressee of the to be published petition if needed, then an e-mail [[e-mailmessages (28)]] alert goes to the other moderator who should moderate it
+* moderator corrects the addressee of the to be published petition if needed, then an e-mail [[e-mailmessages|(28)]] alert goes to the other moderator who should moderate it
 * moderator checks the petition type, corresponds with petitioner if needed, changes petition type
-* moderator gives feedback on petition with suggestions and gives it back to petitioner, status becomes draft again (petitioner + moderator receive e-mail [[e-mailmessages (29)]] alert), feedback is both sent in the e-mail alert as saved next to the petition to be consulted by petitioner
+* moderator gives feedback on petition with suggestions and gives it back to petitioner, status becomes draft again (petitioner + moderator receive e-mail [[e-mailmessages|(29)]] alert), feedback is both sent in the e-mail alert as saved next to the petition to be consulted by petitioner
-* moderator + petitioner receive e-mail [[e-mailmessages (27)]] alert when petitioner wants to publish petition again
+* moderator + petitioner receive e-mail [[e-mailmessages|(27)]] alert when petitioner wants to publish petition again
 * moderator corrects style, spelling and wording of petition where needed
 * moderator chooses subdomain for petition
 * moderator chooses tags best fit to the petition (with autocomplete from the limited set, only admin can add tags)
 * moderator posts tweet about this new petition in a standardised format: subdomain.petitions.eu new #petition "$Titlepetition$"
-* moderator copy-pastes unique link to tweet about new petition to be included in e-mail [[e-mailmessages (30)]] alert
+* moderator copy-pastes unique link to tweet about new petition to be included in e-mail [[e-mailmessages|(30)]] alert
-* publishes petition (e-mail [[e-mailmessages (30)]] alert, including unique link to tweet, goes to petitioner + moderator)
+* publishes petition (e-mail [[e-mailmessages|(30)]] alert, including unique link to tweet, goes to petitioner + moderator)
 Because external moderators (civil servants) sometimes skip tasks, e-mail alerts should also go to us so we can intervene (correct spelling for example).

@@ Regel 136: / Regel 136: @@
 * as above after confirmation
 * future release: every 100 or 1000 signatories and petitioner receives a robot phonecall, just one ring (to make sure petitioner fills in phone number)
-* petitioner receives e-mail [[e-mailmessages|(19)]] with recommendations on how to improve petition
+* petitioner receives e-mail [[e-mailmessages|(19)]] with recommendations on how to improve petition, with a request to login to keep the petition alive, otherwise it goes up for adoption.
-* petitioner receives e-mail [[e-mailmessages|(20)]] when petition reaches date for hand over of petition to addressee and is asked to choose from: 1. change the date 2. organise the hand over 3. revoke the petition
+* petitioner receives e-mail [[e-mailmessages|(20)]] when petition reaches date for hand over of petition to addressee and is asked to choose from: 1. change the date 2. organise the hand over 3. revoke the petition. With a request to login to keep the petition alive, otherwise it goes up for adoption.
 * petitioner changes date of hand over after login on petitions page
-* petitioner receives e-mail when there are 'notifications' about certain signatures: vandalism, famous people signing etc. [[e-mailmessages|(21)]]
+* petitioner receives e-mail when there are 'notifications' about certain signatures: vandalism, famous people signing etc. With a request to login to keep the petition alive, otherwise it goes up for adoption. [[e-mailmessages|(21)]]
-* petitioner receives statistics about performance: how many signatories, growth compared to other petitions, etc. [[e-mailmessages|(22)]]
+* petitioner receives statistics about performance: how many signatories, growth compared to other petitions, etc. With a request to login to keep the petition alive, otherwise it goes up for adoption. [[e-mailmessages|(22)]]
 * petitioner communicates with signatories who indicated they are open for this, they ask admin for help. In ''Future release'' a messaging system and archive of messages between petitioner and signatory. Only signatories can reach petitioner.