Make easier to contribute

[cjoecker]

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

I want to contribute solving issues but I'm struggling to start...
As a beginner contributor with coding experience, this is stopping me to contribute:

1. Which issues are really free to start with. There are many open issues but when I open them, someone is working on it or is going to be done in V5 etc... I label like "free to take" will be helpful. When someone wrote they will do it, assign a person for that will be also helpful.
2. How complex is the issue espected to be. The label "good first issue" is helpful but if I want something mid-level, I don't know where to find it.
3. Best practices to test components changes are missing. How are you guys testing changes on the components normally? In a sandbox? With the docs? In a specific environment?

I hope I can get some guidance so that I can start contributing more :)

[eps1lon]

Thanks for the input! Reducing the barrier of entry is something we're constantly working on but hard to find actionable items without feedback.

I label like "free to take" will be helpful.

We do try to label issues with "good first issue" or "free to take". "free to take" is what we consider good issues for anybody that wants to get more involved.

How complex is the issue espected to be.

If we'd be able to figure this out before working on the issue, we'd get rich doing software consultancy 😄 That's a hard problem that's even harder to get right before working on the issue. Even if we consider some problems harder, they might be easier for others. We're looking for this diversity in open source. By labeling difficulties the way we perceive them we're getting contributors with the same skill set.

Best practices to test components changes are missing. How are you guys testing changes on the components normally? In a sandbox? With the docs? In a specific environment?

Have you checked out CONTRIBUTING.md? I thought this answers this question (explains automated checks and how to fix them, how to write tests etc.).

[cjoecker]

"free to take" is what we consider good issues for anybody that wants to get more involved.

Good to know, thanks!. Still, I think it is missing something to make clear if someone is already working in the issue.

Have you checked out CONTRIBUTING.md? I thought this answers this question (explains automated checks and how to fix them, how to write tests etc.).

What I mean with testing, is not how to write tests itself. With that I mean, if for example there is a component with a bug and I want to fix it, which is the best way you recommend to test the changes. Locally in a new file? In the docs example? Or in a code sandbox?

[eps1lon]

Still, I think it is missing something to make clear if someone is already working in the issue.

I try to assign people to issues if they express that they want to work on it. If nobody is assigned or expressed to do so, you're free to work on it.

which is the best way you recommend to test the changes. Locally in a new file? In the docs example? Or in a code sandbox?

This is totally up to you how you want to go about. What we want to see in the end product is explained in https://github.com/mui-org/material-ui/blob/master/CONTRIBUTING.md#how-to-increase-the-chance-of-being-accepted and the linked https://github.com/mui-org/material-ui/blob/master/test/README.md

[cjoecker]

If nobody is assigned or expressed to do so, you're free to work on it.

Ok, good to know :)

This is totally up to you how you want to go about.

This is good. However, it will help to contribute easier to have a kind of best practices :) I think you have already a good overview of what works well and what doesn't

[oliviertassinari]

If we summarize the thread, we have:

• The good first issue label is applied when we have a working solution, a diff on the issue itself. This target developers that have never contributed to an open source project or Material-UI yet.
• The good to take label is applied when we have a clear direction to go. This targets developer that want to reduce the chance of going down a rabbit hole.
• If nothing happens on an issue for 7-14 days, we can safely assume that nobody is working on it.

For 3. I think that we should encourage contributors to use the documentation website to test the changes out. I'm not aware of any better alternatives.

Regarding the complexity of an issue, why does it matter to you?

---

Do you want to update the contributing guide to include the above in the CONTRIBUTING.md :)? It seems that we miss:

• a better description of "good first issues".
• no description of "good to take".
• explaining that no activity for 7 to 14 days means that there is a high chance that nobody is working on it.
• explaining that the documentation is the best place to test the changes. Maybe renaming the "Testing the documentation site" header into "Testing the changes on the documentation site".

[pedrooa]

I would like to work on that