Baseline for openness and transparency in code repositories for MDN

[SphinxKnight]

Is it normal that mdn/yari#8213 and mdn/yari#9098 (edit: this issue has been edited after this question was filed) are empty of any justifications?

1. How is the community able to know what was intended?
2. Does Mozilla Corporation intend to close mdn/yari source to be consistent with such silence? (edit: addition : and to be consistent with the rationales/justifications being on a closed JIRA)
3. If not, can Mozilla Corporation development team follow sane guidelines for open source development as they would probably expect from some other contributors?

[SphinxKnight]

see Principle #8 of https://www.mozilla.org/en-US/about/manifesto/ "Transparent community-based processes promote participation, accountability and trust."

[LeoMcA]

• The primary point of the PR description is to provide an explanation and context for reviewers
• Sometimes we give each other that context internally as part of our everyday work and regular meetings, though in these cases I agree we've sometimes fallen short of our ideals in making those context/decisions public - which can end up hurting us in the long run, if we forget why or how a decision was reached
• Sometimes we're not able to share that context externally because of security-sensitive fixes or embargoed features

1. How is the community able to know what was intended?

• Ask! Leave a comment in any PR asking for the context surrounding it
• We might not be able to respond immediately, but at a certain point everything should become public knowledge in the end
• And indeed some things, which we're not aiming to widely publicise at that point in time, can still be shared privately with trusted community members (such as you!)

2. Does Mozilla Corporation intend to close mdn/yari source to be consistent with such silence? (edit: addition : and to be consistent with the rationales/justifications being on a closed JIRA)

• No

3. If not, can Mozilla Corporation development team follow sane guidelines for open source development as they would probably expect from some other contributors?

• I believe we do, and we hold ourselves to the same standards as we would hold contributors (just ask Florian or me about how many times Claas has reminded us to fill in the PR template, and rightfully so!)
• But, as stated before, sometimes we can't: due to working on embargoed or security sensitive pieces of work
• Crucially, these are not things we expect the community to work on, that's our responsibility as full time engineers on the project
• But, as also previously stated, you're always welcome to ask questions about these things after they become public knowledge

[SphinxKnight]

Thank you for the answer @LeoMcA 🙇 much appreciated.