Open Source Software Primer: Providing Support

What is "Support?"

It can be difficult to know where to start when contributing to open source, but a nice easy way to dip your toe in is by providing technical support (or assisting with it). "Support" can be (very) broadly broken down into two categories:

1. Questions & Answers
2. Quality Assurance/QA

1. Questions & Answers

If the project you want to work on has users then inevitably there will be questions. What's more, those questions may contain a lot of "dumb"* material that could probably be better answered by reading the documentation. However, those questions still need answering and it's not a good look to berate people engaging with your project. We don't know why these questions are being asked and we should always give the poster the benefit of the doubt where possible. What's more, if you see the same "dumb" question being asked repeatedly then this could be a sign that your docs aren't as clear as they could be. An easy way to start contributing right away is to answer these easy questions sincerely. Sometimes people will ask questions that have already been asked and answered elsewhere. You can point people to these if you need to. You can become a common presence on the forum, and know which people to ping when certain questions come up.

* In reality there is no such thing as a "dumb" question, but as a developer you will frequently encounter questions that seem so to you. It's always worth remembering that when it comes to weird questions there is usually no smoke without fire! If this user came to this strange conclusion, have a look at your docs and think about how or why they did. 

In PyMAPDL you can find questions in two main places.

• The "issues" tab & "Discussions" tab
  • For bugs, feature requests, and tasks
• The forum (discuss.ansys.com)
  
  • Technical support, discussion, community

Issues & Discussions

The main page, and centre of the development process, for many open source projects (including PyAnsys) this a GitHub page. Given how chaotic the development process can be (even in closed source), it is best to keep the issues on here on topic. GitHub is not the place to be asking for help with the project (unless your open source project is particularly small). It is best suited to reporting/discussing bugs, and making explicit feature requests.

The forum on the other hand is a lot more general and is the best place for technical support questions like "how do I do X in this version?", or "will the next version support Y feature and when will it be out?", but you may see development questions too. There will often be overlap between the two sites, both in terms of content and users, but there will also be plenty of people who'll post the wrong questions in each. These questions will need to be moved between the sites and that's where you could come in, for example. Otherwise, familiarising yourself with these forums, asking questions and making content is a great way to get to know the community, how to navigate it, and contribute in a meaningful way.

A note for Ansys employees: remember that questions on PyMAPDL will (almost certainly) be public and when helping someone you're actually helping everyone who'll ever read what you post. That means avoid posting links to internal materials, or even links at all! Try to keep any answers you have self contained.

2. "Quality Assurance" aka QA testing

For details about what QA testing is you should read my guide to the development cycle as a whole. Open Source Software Primer: The Development Process. So, what can you do to help? A decent blog post about contributing to QA in open source can be found here, but I've summarised 5 things you can do to help below.

1. "General, Manual Testing"

   a. This just means "use the code and report errors"

   b. Take the latest release and use it!

2. Bug Reproduction

   a. Find an issue

   b. Verify the bug can be reproduced. Add any new info to the ticket.

   c. If you can't then the bug may not be in the project!

3. "Specific, Manual Testing"

   a. Clone a pull request and test the code before it is merged

   b. Look at issues that have been "fixed". Independently check they have been fixed. If not, then reopen them.

4. Read the documentation

   a. Proofread the docs

   b. Check the logic in the examples. Developers may be software experts but they aren't necessarily domain experts!

       c. Test the examples out.

1. Write tests

   a. All code should be tested.

   b. Find code without tests -> write tests for it!

Conclusion

In conclusion, there's always more support to be provided! Be it in the forum fielding simple questions from new users, or on the GitHub page testing out fixed features to make sure they work as intended, there's always an area where you can help out. They are ideal for people who don't feel particularly confident about coding yet but still want to contribute. They provide a way to get comfortable with the codebase and the development cycle if you aren't already familiar. You can learn a lot through providing support and get yourself recognised by the community. There are always jobs to be done and in particular developing documentation is a very low-risk, low-consequence, way of doing it.