If you're an active member of the xTuple open source community, or you want to get more involved, or you're new to participating in an open source community altogether, then this post is for you.
Have you ever wanted to tell us that something is missing from or not quite right in xTuple ERP? You can tell us by entering a bug report or a feature request. If you have submitted a bug or feature via incidents on our Issue Tracker, did you wonder what happened next? I recently updated the xTuple GitHub wiki with step-by-step instructions and some definitions to help you.
There's a natural separation or split in the workflow. The first part is telling xTuple (or any software project or vendor, for that matter) what the problem is and coming to agreement on severity and priority (those are not the same!), and on the general nature of a solution. The second part is following a consistent process to address that problem — fix the bug or add the feature — and create a record of what was done.
Bug and Feature Request Creation
Bugs
If we don't know about it, we can't fix it. If you are using xTuple software and find a bug, we'd love to hear about it. Or if you think the software is missing a critical feature, please let us know. Our GitHub wiki describes the basics of bug-reporting for xTuple's software. This includes OpenRPT, CSVImp, the xTuple ERP desktop client, xTupleCommerce, and any of our open-source and commercial extensions.
Writing good bug reports is hard work. The best description I've ever read: How to report a bug (and why) by Simon Tatham.
Features
If we don't know what is needed and what "it" is, we can't add it. Sometimes it's obvious that the software should do more. Usually that more sounds really straightforward, like "A point-of-sale application should just calculate sales tax." Don't be surprised if this leads to a long conversation. As a user, you don't care about the details, and you shouldn't have to. As a developer, it's my job to care about those details: If the application calculates sales tax, is that for Virginia or some other state? What about Virginia's "sales tax holidays" (no tax on school supplies and certain clothing for one week in August, a different week for hurricane preparedness supplies, etc.)? What about the rest of the world, other country's needs?
Somehow you — the user — and I/we — the developer — need to reach an understanding: What is the extent of the problem? What is the extent of the solution? What will we leave out? One problem I've encountered many times is that people take offense where none is intended. That seemingly-endless barrage of questions and details is an essential part of resolving the problem. It's a developer's way of learning from you, the expert user.
Reality
We can't do everything. There's the obvious constraint that we can only do so much in a day. There are actually problems more challenging than that. For example, we can't both do and not do something. As a specific example, some people want to create work orders from sales orders and other people don't; therefore we needed to choose: calculate, don't calculate, or make it optional. Now for the impossible part — we can't make this and hundreds of similar features optional and keep configuration simple.
Bug Fix Workflow
The second part of the split mentioned above is the bug fix workflow. At least two different people are involved in this, the coder and the reviewer. This ensures that two or more people read the code to see if it does the job — fixes the bug or adds the feature — as desired. Bug fix workflow responsibilities and bookkeeping tasks are also documented.
You might find that page interesting, even if you don't actually change code. It should help you understand some of the comments attached to your bug reports.
There's still more to do after the code has been fixed, such as integration testing and documenting changes. Those steps are not yet documented. We frequently update these wiki pages to add details and clarity, so stay connected for the most up-to-date information.
What else would you like to know?
Gil Moskowitz
Gil joined xTuple in 2005 to develop the first version of multi-currency support in our products. He helped xTuple transition from its original closed source OpenMFG product to the commercial open source company we are today. Before coming to xTuple, Gil worked for several large and small software companies in a variety of roles, including Informix Software, where he managed the database backup/restore utility group. He always advocates for, and delivers, high-quality products through improvements to the software development process. Ask about his other jobs next time you see him — ! He has a B.A. in Biology from Reed College and an M.S. in Computer Science from Old Dominion University.