Welcome and thanks for taking the time to contribute, it's great to have you here!
This is a set of guidelines for contributing to abap2xlsx. Mostly guidelines, not hard and fast rules: try to apply your best judgment and, when necessary, feel free to propose changes to this document via pull requests.
We use the SAP Community Network as our discussion board for general questions concerning the usage of the library. You can search for all content containing abap2xlsx before you post a new question. You also can limit the search using the tag: abap2xlsx. Please use this link when you want to post a new question the tag abap2xlsx will be prefilled).
While the discussion board is meant for general how-to questions, if you have found a bug or simply wish to inquire about a new feature please file an issue on GitHub and provide as much relevant information as possible: a well-written bug report is truly helpful.
We have the channel #abap2xlsx in the SAP Mentors & Friends Slack. You can get yourself an invite here.
Changes are handled via the usual pull request mechanism; clear, short PRs for bugfixes are best because they're easy to review but sometimes, especially with new features, the changes are more substantial: in this case please provide an overview and pointers to the most relevant changes to be checked. If possible, a PR should not exist in a vacuum, rather it should address or even close an issue already filed. This way, the relevant context can be provided without cluttering the PR itself. Last but not least, there is a separate document dedicated to the coding guidelines.
With the possible exception of the original authors it is recommended that contributors go through the PR process, even when they have push access. A different contributor will then review the PR, provide feedback on possible reworks or even merge it directly if all is in order. It is also possible to review changes and have someone else merge them, of course.
When the review process takes a long time, regardless of the reason, the changes proposed by the PR might fall behind the master branch. If the author of the PR has allowed it (default setting in GitHub), another contributor might come along and merge the master branch into the PR branch, thereby freshening it. When conflicts happen, however, the PR author should resolve them. By all means, if necessary ask for help in the conversation section of the PR. If a PR lies dormant for too long, an effort will be made to get in touch with the author, to ensure the request is still relevant.