Watch your language ... or how beeing nice makes quality contributions
Created by: riyad
This is a non-technical issue ... this will be about the community and contributors and how we talk to each other. DISCLAMER: This is not meant as a personal assault on anybody ... its about the climate of discussions that I came to witness from time to time.
I like GitLab and I want it to become a great piece of software. That is the reason I put up with certain things, but I'm not happy. :( And language plays a major role in this.
There a several obvious and subtle ways communication can go wrong. :( And the international nature of Open Source projects makes things more complicated. There some exemplary situations I have witnessed ... that should make it clear what kind of situations I mean. It seems like nitpicking, but if you have to read this over and over again it hurts.
- Not everyone speaks English as their first language so there will be misunderstandings. "I don't quite get what you mean. Can you explain it in another way?" might be a nice response.
- As a maintainer you can expect a certain quality from contributions. If they don't, you can demand it being updated and resubmitted. "tests fail" might be correct, but not as nice as "Tests fail here, can you please recheck?"
- It might not always be obvious what a MR changes. "Can you provide a screenshot?" or "Can you explain in more detail?" are cool.
- Sometimes a contribution extends GitLab beyond what the maintainers are willing to support. After a long discussions the contribution is rejected. But the criteria for contributions is not updated to clarify what will be accepted or under what circumstances the rejection might be reconsidered.
- Some people don't contribute code, but none the less use GitLab and follow the issues and participate in the discussions. Looking down on non-code contributors is a foul.
General rules
This is a general list of the things I found could have made the above examples a lot nicer.
- Sentences are nicer than words.
- Questions are nicer than demands or statements. Even if you mean them the same way. ;)
- If contributions do not meet the acceptance criteria, point them to a checklist and ask them to resubmit.
- Always be friendly, never get personal.
Broader topics that need to be addressed (IMHO)
There are common issues in all Open Source projects and they need to be addressed. I have come up with a small list from the top of my head, but there are probably other things as well. ;)
- what makes regular/casual contributors
- make it clear what (quality) you expect from contributions
- how to handle vague and/or nonsensical (feature) requests
- making clear when extending support for other platforms/features is acceptable
- document the outcome of (general) discussions so they are visible to other/later contributors
- ...
I don't want to present solutions at this moment, as this must be handled as a community. So, let the discussion begin ... :)
Name calling and pointing out in the comments who did what, on what occasion is totally missing the point I'm trying to make. ;)