Contribute/barriers
This article is a stub. You can help MozillaWiki by expanding it.
The purpose of the Contribute barriers page is to document instances of where members of the broader Mozilla community ("Mozillians") encounter barriers when trying to contribute in the open on Mozilla projects.
Mozillians can only contribute to things they understand and have access to.
Working in the Open means that not only is your code findable, but so are the things that lead to the decisions behind the code changes. There are a _lot_ of tools that default to closed, because that's the way that most businesses want to operate. Mozilla is not like that. Our super power is the fact that folk outside the company are our peers and can take part in building products that folk want to use, because they helped craft them.
Some of these closed tools that we use now include Confluence (instead of a Wiki), Jira (instead of Bugzilla), Slack (instead of Matrix), Figma, the Google Suite (where we don't share documents as "Public"), etc. This can lead to us filing bugs or land features that say "Closes [DISCO-1234]". If someone outside the org does not know that DISCO-1234 is, or that it's part of the overall project defined by IQKR-60609 which impacts PEN-6500, they will be as confused as you are that you can't find any references to those because I made most of them up. So, instead, they'll generally presume the worst, or just try and block people from using he feature because they have no idea why it should be there at all. There is a long, often repeated history of this occurring in the past.
It's also worth noting that using closed tools also often means losing the data that was generated by those tools. That could be cloud storage systems that lock away data when the subscription ends, or remove data after some period, or just prevent unauthorized (or non-paying) individuals access. This may mean that folk who are not part of the immediate team may not have access to the data either.
There is still absolute cases where private, internal tooling is required (when there is an ongoing security incident that needs to be addressed, when there are partner credentials that need to be shared, when there are discussions about internal employee services or actions) but in most cases we should Default to Open whenever possible. If you can't follow the reason for a decision back as close as possible to the source of truth using a browser in Private mode, then no one else can. If there's good reason to prevent further progress, be verbose as possible at the point where we can become public.