Contribute/workmode: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Intro)
(copy edit intro, move dfn of page / why outside of is Firefox still open source, Questions section)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{stub}}
{{stub}}


<big><br>
The '''<dfn>Contribute workmode</dfn>''' 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 are also using the [[Contribute/barriers|barriers]] page to identify processes or habits that are barriers to good faith (per [[CPG]]) community participation and what steps can we take to minimize and ideally eliminate any such barriers.
'''[https://www.mozilla.org/en-US/about/manifesto/#principles-08 Mozilla Manifesto Principle 8]''':</big><br>
“'''Transparent community-based processes''' promote participation, accountability and trust.”<br>
<br>


===Is Firefox still open source?===
== Why ==
This page is an effort aligned with '''[https://www.mozilla.org/en-US/about/manifesto/#principles-08 Mozilla Manifesto Principle 8]''', specifically:
<blockquote>“'''Transparent community-based processes''' promote participation, accountability and trust.”</blockquote>


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 '''<dfn>Contribute workmode</dfn>''' 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.
== Is Firefox still open source ==
Of course Firefox is an open source project according to any common definition!


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 principles, processes, and practices.


<br>
__TOC__
__TOC__


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:
* ...
== Success Criteria ==
What does success look like, how do we measure our progress towards success, and are there "conditions" to pass to indicate levels of success?
Brainstorming:
* When new community members have:
** … clear and welcoming onramp to contributing to Firefox and other Mozilla projects
** … fewer/no login-wall obstacles with a few noted exceptions (e.g. security bugs)
* ...
== 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.)
* ...
== Questions ==
Got a question about how to [[contribute]] to Mozilla, or especially about this page/project to improve the open contribution workmode at Mozilla? Ask away and hopefully someone working on this in the community will be able to both answer your question, and use it to improve our [[Contribute]] documentation.
* ...
* ...



Latest revision as of 22:58, 29 October 2025

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

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 are also using the barriers page to identify processes or habits that are barriers to good faith (per CPG) community participation and what steps can we take to minimize and ideally eliminate any such barriers.

Why

This page is an effort aligned with Mozilla Manifesto Principle 8, specifically:

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!

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 principles, processes, and practices.

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:

  • ...

Success Criteria

What does success look like, how do we measure our progress towards success, and are there "conditions" to pass to indicate levels of success?

Brainstorming:

  • When new community members have:
    • … clear and welcoming onramp to contributing to Firefox and other Mozilla projects
    • … fewer/no login-wall obstacles with a few noted exceptions (e.g. security bugs)
  • ...

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

Questions

Got a question about how to contribute to Mozilla, or especially about this page/project to improve the open contribution workmode at Mozilla? Ask away and hopefully someone working on this in the community will be able to both answer your question, and use it to improve our Contribute documentation.

  • ...

See Also

Subpages of Contribute