Developer Interaction Tips

Sometimes interactions between developers can be tricky. The project aims to be inclusive and supportive of different use cases and perspectives, encouraging people to be productive and enjoy working with it and its community. We appreciate that some people find interactions more challenging due to language barriers, particular ways of thinking and the many different ways people approach problems and challenges. We've tried to document some things to keep in mind (in no particular order):

• The problem you're currently working on is going to clearly be important and the most pressing thing to you. Remember that other people have their own priorities and will be working on different things so they might not be as excited/interested in it as you are.

• Whether others engage on an issue or not isn't a good measure of how important it is, it would likely be more a factor of whether anyone has appropriate experience/knowledge and can offer any useful input. Everyone has a different background and nobody knows every different area.

• You might wonder why to you, there is such a glaring obvious hole in the project in some way. Perhaps people haven't approached things from your direction before. Perhaps they don't have your knowledge or expertise. It is very unlikely to be a purposeful omission. Anything unusual done purposefully will usually be documented as such.

• Whilst there may be a wonderful way of doing things that you can see, it is probably impractical that big changes can happen quickly and everyone can just change to that, much as everyone would wish otherwise. For a variety of reasons, changes often need slower incremental steps towards an end goal. This may feel frustrating but it is amazing over time how much change you can actually make. It does need patience.

• Criticising an existing approach or code may make people defensive even if they also don't like it. There are often reasons why things end up as they are, even if they are far from perfect. They probably did improve on something before them, the people involved probably learnt things since and would love to redo it with that hindsight or new knowledge too. Approaching things as suggesting incremental improvements is usually more productive rather.

• Maintainers have to view changes from multiple perspectives and balance the needs pf many different and often diverse users. If they suggest caution or potential problems or ask for improvements to a change, it isn't to be negative but to try and ensure any change has the best chance of getting included. Maintainers do actively want code improvements and contributions.

• Remember than when asking for something to be included, maintainers are acutely aware that once merged, you will probably move on to other things and they will be left looking after it going forward. This may mean they ask questions, it may make then reluctant to take a change if they don't want to be left maintaining it. If you think you will be around and using it and able to help in future, making that clear may help. Also try and be clear if you cannot help any more.