Help LabRPS
Introduction
If you like LabRPS and would like to help the project, there are many things you can do, no matter if you prefer to invest time or money, or if you know how to write code or not.
Donate money
Although LabRPS doesn't need money to be developed, donations can help the project to grow further and faster. The Donate page lists all the options you have to donate money to the project.
Work on the documentation
Help us to build, correct and extend this documentation. Correct mistakes, extend or correct pages that are unclear, create new pages if a topic is missing, etc. Contributing to the LabRPS wiki is easy, at WikiPages you can find the general guidelines and the help needed to get you started. To edit the wiki, you will need a wiki account with "Editor" permissions (the wiki is write-protected to avoid spamming). You can ask for an account on the forum. The official LabRPS forum should be the premier place to ask questions and start discussions, As it will help preserve the experience and knowledge of the community.
A couple of areas that would welcome your work:
- The Category:Command Reference page lists and documents all of the LabRPS commands. Most of them contain little to no information at all. Please refer to WikiPages for good examples of what command documentation pages should look like.
- The Tutorials section needs examples on how to use the plugins. If you developed something cool with LabRPS, why not document how you did it for posterity?
- There are open tickets on the LabRPS "bug tracker" tagged "documentation" that could use.
The user community around LabRPS is still small, but already includes several advanced users who do a very important job in showing to newcomers how to use the software. If you begin to feel comfortable with LabRPS, your knowledge could be very valuable to others, and you might contribute with important assets, like:
- Showing the work you do with LabRPS on the Users Showcase forum. You can post screenshots, and, even better, attach the LabRPS files so other people can examine it and understand how you did it.
- Recording videos showing how you did something interesting in LabRPS. These videos usually do a great job in showing new features.
- Write tutorials describing or teaching something interesting. You can write tutorials on your own blog, directly on our wiki, or even on the forum.
- Post on the Mastodon open source social network (and follow LabRPS there), on the Facebook community or on Twitter (and follow LabRPS there). Use the hashtags #LabRPS, #MadeWithLabRPS or #rps to make your LabRPS-related posts easier to find by other LabRPS users.
Help others to know LabRPS
- Talk about LabRPS to other people who might be interested
- Find interesting uses for LabRPS, and document it, for example with screenshots. LabRPS is very young, and not many people see what they can do with it. If you are a LabRPS fan already, you surely know some cool thing LabRPS can do. Help us to show that to others!
- Hang on the forum, and help newcomers to solve basic questions
- Write tutorials, record videos, etc., showing what you do with LabRPS
- Contribute with files, drawings, etc. We still lack good example files of what can be done with LabRPS
- Help to promote LabRPS on GitHub by "Starring" and "Watching" the LabRPS repository
Report bugs and ask for interesting features
Although the place to report confirmed bugs and suggest new features is eventually the LabRPS Tracker, please always post bug reports and feature requests to the Help forum first. In order to save developers time (triaging and handling hard to understand bugs can be very time consuming), and avoid frustrations because your issue was not handled the way you would like, please read the following:
- Bugs and features requests are handled in the same tracker. Just mark your issue as "bug" (something that doesn't work as it should) or "feature" (something that is not there but you think it would be good to have)
- Although originally you could submit issues anonymously, unfortunately this had to be cancelled due to spam. Now if you would like to create/edit tickets you will have to create an account. You will then by default be notified when someone adds notes to the issue. In many cases, the person who will handle the bug will need more information from you.
- When reporting a bug, the most important point is to allow developers to reproduce it. Be sure to include the exact steps needed to make the bug happen, so another person can do the same and see the bug happen on his machine too. If the developer cannot see the bug, he cannot solve it either.
- Also include information that can help developers to situate the problem, like the operating system you are running LabRPS on, the exact version of LabRPS and the relevant libraries. Please post all the data by using the "copy to clip board" button in the Help (menu) → about LabRPS dialogue.
- No matter how sure you are that you have found a bug, please always discuss bugs first in the Help forum.
- Before submitting a feature request, always discuss it with other users first on the Open discussion forum, so you might end up with a more solid proposal, with more chances to interest a developer to implement it.
- Remember that LabRPS is developed by volunteers who use their free time to work on it. Although everyone tries his best to make the best possible application, your bug report might be treated with low priority, or canceled if you cannot give sufficient information, and your feature request might be postponed or even refused if no developer has interest in implementing it or if that would request an unrealistic amount of work.
Triage bugs
There are dozens of bugs reported on GitHub weekly. It takes a lot of time to read them, categorize them, verify if the issue is reproducible, see if some easy actions can be done, or ask the person who posted the issue to provide more information. Helping to triage is easy, just head over the GitHub and start commenting on any issue where you think you might be able to help!
Design artwork
See the Artwork and Artwork Guidelines page for guidelines about designing icons for LabRPS.
Write code!
Writing code for LabRPS is not hard, and you don't need any permission, you can start right now to work on something you want, then submit a patch on the issue tracker or request a merge from a git branch. To avoid headaches you should meet the following prerequisites first:
- Information how to compile LabRPS is available for different operating systems.
- Before you start to code for LabRPS, you must know how LabRPS works. This seems obvious, but if you don't know how it is supposed to work you won't know what to do internally or how to do it.
- Almost everything can be done either in Python or C++. The internals work almost the same in both languages. We suggest you read through the Power users hub pages, even if you're going to code in C++ since it will give you a good overview of the internals.
- LabRPS is mainly coded with C++, so you need to make sure you can compile LabRPS without problems first.
- Present yourself to other developers. LabRPS is before anything a social project, we discuss a lot of things on the forum before implementing it, and it's always best to discuss your ideas and tell people what you are planning to do before actually doing it. The forum is the one and only place where you can meet all the developers.
- More and more of the LabRPS functionality is not written in the LabRPS code itself but in plugins. This is what makes LabRPS powerful. Oftentimes, working on an plugin is easier because there is less code to read and understand, and fewer people involved. check the Plugins repository to get some ideas!
User documentation
- Getting started
- Installation: Download, Windows, Linux, Mac, Additional components, AppImage
- Basics: About LabRPS, Interface, RPS Objects, Object name, Preferences, Workbenches, Document structure, Properties, Help LabRPS, Donate
- Hubs: User hub, Power users hub, Developer hub