Contribute/workmode: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(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.)
* ...
* ...


Revision as of 15:52, 16 October 2025

This article is a stub. You can help MozillaWiki by expanding it.


Mozilla Manifesto Principle 8:
“Transparent community-based processes promote participation, accountability and trust.”

Is Firefox still open source?

Of course Firefox is an open source project according to any common definition! But provocative rhetorical question aside, there is a huge difference between mere open source code and a project with a vibrant open source community. Such a community doesn't just happen, it can be encouraged or discouraged by our processes. The Contribute workmode page is a work-in-progress for documenting how we work in the open, and how to document how to contribute to various Mozilla projects, and ideally how to contribute to this page itself. We will also identify processes or habits that are barriers to community participation.



Current Practices

Our current practices for working in the open.

See Contribute for how to work in the open various Mozilla projects.

E.g.

Barriers

See Contribute/barriers for specifics and more.

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.)
  • ...

See Also

Subpages of Contribute

Retrieved from "https://wiki.mozilla.org/index.php?title=Contribute/workmode&oldid=1255424"