MDN team is holding a GitHub work week!

[Rumyra]

👋 Hey folks!

The MDN team is holding a GitHub work week beginning July 8th. We’ve held previous weeks which are similar to give us some time to focus on processes and a bit of spring cleaning. We’ll concentrate on a different area each day - this is the current agenda:

• Monday - Stale PRs & issues across the org
• Tuesday - Teams & roles
• Wednesday - PRs and the review process
• Thursday - Discussion triage process
• Friday - Issue triage process

If you have any feedback about any of our current processes you’d like to share, feel free to add it to this conversation or message us in Discord - thank you.

[OnkarRuikar]

About good first issues, there should be a time limit for an issue to remain good first. Regular maintainers defer(or are supposed to defer) these to newcomers and if no one picks it up then the issue remains unnecessarily unsolved. For example, Wrong explanation of the example inside Inline formatting context

The PR labeler could be configured to remove the good first label after a month.

[Josh-Cena]

A maintainer can fix a good first issue in 5 minutes(minus git and GitHub boilerplate). So why hold good firsts back after 289 (now 301) issues?

Because maintainers can fix other issues in less than half a day while it would take new contributors infinite time to do so (read: they won't do it). Maintainers aren't here to just close issues. It doesn't do you much good to close a good first issue. As I said, it's not going to significantly affect content even if good-firsts are left open. I would encourage you to not fix anything that's obvious how it should be fixed, and focus on the hardest tasks first (e.g. ones that require updating several related pages, or ones that require reading the spec).

[OnkarRuikar]

I would encourage you to not fix anything that's obvious how it should be fixed, and focus on the hardest tasks first

I think fixing small ones first will bring the issue count down faster, that is why I picked the ones which had been triaged. This month we've been bosting how many we closed in the last month, so you are contradicting here. Also, no official person has conveyed to me that fixing big ones is the priority. 🤷

( e.g. ones that require updating several related pages

I would like to exercise freedom of how much time I put into contributing. Don't pressure me.

(e.g. ones that require reading the spec).

This is rude! You imply I don't read specs while fixing issues.

[Josh-Cena]

I think fixing small ones first will bring the issue count down faster, that is why I picked the ones which had been triaged.

The priority is not to get the issue count down as much as possible, no. Well it is in a sense but not indefinitely. We need to leave sufficient number of issues for new contributors, and fixing other issues is just to make these contribution-friendly ones more obvious. The goal was always to triage them, point out what exactly needs to be done so others can take it up, and fix things that new contributors likely won't take up, such as big ones and ones that need reading the spec.

"Triaged" also doesn't mean they are easy. Sometimes it's clear something is wrong, but it's not easy to fix it. For example, mdn/content#34670, which requires spec-reading and understanding page structures.

Also, no official person has conveyed to me that fixing big ones is the priority.
I would like to exercise freedom of how much time I put into contributing. Don't pressure me.

Again, we are all community contributors here. I'm not pressuring you. You can fix good first issues. You can choose to fix zero issues. There's no commitment here. I'm saying that as someone with both professionalism and close relationships with the project, it's good etiquette to leave easy things to others.

This is rude! You imply I don't read specs while fixing issues.

I'm saying the exact opposite: that you have the habit of reading the spec while fixing issues. Other contributors don't. Which is why you are uniquely positioned to fix more advanced issues: your PRs will be backed by more facts and face less scrutiny.

I'm not implying anything you are doing at the moment is wrong. Your PRs mostly tackle hard issues that need spec reading and technical understanding. I'm saying good first issues need to be left as good first issues and only fixed when we've fixed everything else—that's all. We have >150 issues that we will likely never fix (per our query), it doesn't hurt to add another 20 or so to this list.

[pransh15]

Hi Josh and Onkar,

Thank you both for sharing your thoughts on the issue. After discussing with the MDN team, we we think leaving some good first issues available for new contributors would be great. While there isn't a guideline preventing maintainers from resolving good-first-issues, we aim to strike a balance. For example, ensuring at least ten good-first-issues are available for new contributors, while maintainers continue with their ongoing tasks.

@Josh-Cena, I appreciate you echoing our conversation from a few weeks ago, our goal isn't to reduce issues to zero but to have an inclusive community where some space for new contributors to come in. This aligns with the ethos of MDN and Mozilla, which prioritizes working openly and maintaining an inclusive environment for all contributors.

That said, I regret that the discussion comes across harshly to @OnkarRuikar. Josh, I understand the spirit in which it was said, and your intentions, but the delivery may have seemed a bit abrupt. Let's work together to resolve this amicably.

Thank you both for your understanding.

[Josh-Cena]

I understand the spirit in which it was said, and your intentions, but the delivery may have seemed a bit abrupt. Let's work together to resolve this amicably.

I'm sorry if it came across as abrupt. I meant absolutely no reprimand. I hope my last comment had already clarified my intention.