canmove, Confirmed users
2,887
edits
(Intro) |
(add Explorations) |
||
| Line 27: | Line 27: | ||
Summary of where community members have run into barriers or obstacles to working in the open on Mozilla projects: | Summary of where community members have run into barriers or obstacles to working in the open on Mozilla projects: | ||
* ... | |||
== Explorations == | |||
Ideas for specific projects to help with working in the open. Each could be started as a WikiMo page. | |||
* '''Warning lights''' - detect when things go wrong (preferably checks that can be automated) | |||
** e.g. link to jira ticket or confluence page in a bugzilla bug | |||
* '''Runbook''' (create new) — How to react when things go wrong, when a warning light goes yellow or red (literally via automation or metaphorically someone raises a yellow alert or red alert) | |||
* '''Openness metrics''' for criteria, or ranking of how “open” a resource/feature/project/product is, can a drive-by observer understand how it works, who is working on it, who worked on it recently etc.? E.g. contrast the flatness of Bugzilla and WikiMo to MDN or Sumo (e.g. https://support.mozilla.org/en-US/kb/content-community-best-practices-bugzilla-tickets) which require login to view History etc. | |||
** What are all the different ways we mean “work in the open”? (source, bug tracking, change control, decision-making, review, etc.) | |||
* ... | * ... | ||