Changes

Jump to: navigation, search

Reps/Council

4,649 bytes added, 15:22, 25 August 2018
Add accountability
''NB: if a Council member realises that (s)he must be absent from the program for more than 1 month, then the Council must be notified as soon as possible in order to find a permanent replacement. ''
 
== Peers holding Council accountable ==
 
The [[Reps/Peers|Reps Peers]] are responsible to hold Council accountable to their tasks.
 
=== Activity ===
 
* Every Council member should participate (not only reading) in discussions happening on Discourse and the Council alias
* Every Council member should regularly participate in meetings - there are exceptions of course as Council members usually are very distributed and have day jobs. If somebody is not able to attend feedback and updates should be left in the meeting notes before the meeting and the full meeting notes should be read after the missed meeting to get up to date again.
* Every Council member should work on their assigned OKRs and give regular status updates
* Every Council member should give feedback for other working documents and discussions
* Reps Council should actively engage in Open Innovation discussions and be up-to-date on recent developments by following the Monthly Open Innovation Calls (either live or recorded, or by consulting the slides and looking up important information in the recording if something is not clear)
* Every Council member should write small reports on the Reps Portal when they do activities for the Reps * Program (such as writing a document). This does not need to be granular (“Finished document A so it’s ready for Council review” instead of “I wrote one sentence in document A”). This is additional to the regular updates in the GitHub issue as long as we don’t take GitHub activity into account for Portal reports/activity.
* Every current/future Council member should agree to use Github for sharing updates and activities
 
=== Documentation ===
 
* Every Council member should give a small update after every quarter summarizing their work (mostly OKR related)
* Every Council member should create issues to document their work in the Reps GitHub repository and keep them up to date
* Decisions should be recorded in the voting tool by creating votings.
* Finished working documents should lead to a post on Discourse to update Reps
* Where applicable, feedback should be gathered before starting a working document to gather Reps feedback and to inform them about what the Council member is gonna work on
* OKRs should not be published later than 3 weeks into the quarter
 
=== Asking for Peers feedback ===
 
* Council should ask Peers actively for feedback - Peers can however give feedback without a specific ask - feedback doesn’t need to be on a working document, this can also be in the middle of a discussion in Discourse. The Council members ask Peers for feedback for strategic parts of their working documents once Council reviews those as well. Feedback can of course be asked already before that if valuable (e.g. “what do you think of this direction?”). Council members can also give feedback to Peers whenever they see fit.
* Council should make Peers aware of any conflicts or escalations as soon as they are aware of it
* Council can define a “bridge person” (does not by default mean the current council chair) that interacts with Peers on a regular basis if Council decides to do so
 
=== Workflow / Prioritization ===
 
* Council Updates in the Reps Weekly Call should be distributed among the Council members so it’s not always the same person doing the update. This should be decided async by the Council before the call. The Peers advice this to be done as an action item during prior Council call.
* OKRs and responsibilities should be equally distributed by taking into consideration bandwidth and availability of the council members.
* OKRs should have high priority, other business (except conflict resolution and top priority incidents) should be planned for the future (next quarter OKRs for example)
* Council members should work together on the OKRs, provide timely feedback to not block each other
* Council member should fill out the timeline for the OKRs they are responsible for to identify possible resource problems (vacations, day job, …). OKRs with identified shortcomings in resourcing should have at least one other Council member supporting.
 
== Interaction of Peers and Council ==
 
* Peers give context of previous discussions/incidents in day-to-day discussions where needed
* Peers give feedback where they think it’s valuable without being asked
* Peers help with the OKR process by reviewing and giving feedback to OKRs early in the process
* Peers help with the Reps program vision by providing reviews and feedback to longer-term plans
* Peers are heavily involved in strategic discussions around the Reps Program and are always part of strategic discussions
== Contact the Council ==
Confirm
550
edits

Navigation menu