nealrichardson commented on a change in pull request #7520: URL: https://github.com/apache/arrow/pull/7520#discussion_r444533246
########## File path: docs/source/developers/contributing.rst ########## @@ -76,46 +96,83 @@ visibility. They may add a "Fix version" to indicate that they're considering it for inclusion in the next release, though adding that tag is not a commitment that it will be done in the next release. -Advanced use ------------- - -Once you are involved in the project and want to do more on JIRA, such as -assign yourself an issue, you will need "Contributor" permissions on the -Apache Arrow JIRA. To get this role, ask on the mailing list for a project -maintainer's help. - -GitHub issues -------------- - -We support `GitHub issues <https://github.com/apache/arrow/issues>`_ as a -lightweight way to ask questions and engage with -the Arrow developer community. We use JIRA for maintaining a queue of -development work and as the public record for work on the project. So, feel -free to open GitHub issues, but bugs and feature requests will eventually need -to end up in JIRA, either before or after completing a pull request. Don't be -surprised if you are immediately asked by a project maintainer to open a JIRA -issue. - -How to contribute patches -========================= - -We prefer to receive contributions in the form of GitHub pull requests. Please -send pull requests against the `github.com/apache/arrow -<https://github.com/apache/arrow>`_ repository following the procedure below. - -If you are looking for some ideas on what to contribute, check out the JIRA -issues for the Apache Arrow project. Comment on the issue and/or contact -d...@arrow.apache.org with your questions and ideas. - -If you’d like to report a bug but don’t have time to fix it, you can still post -it on JIRA, or email the mailing list d...@arrow.apache.org. +Tips for successful bug reports ++++++++++++++++++++++++++++++++ + +No one likes having bugs in their software, and in an ideal world, all bugs +would get fixed as soon as they were reported. However, time and attention are +finite, especially in an open-source project where most contributors are +participating in their spare time. In order for your bug to get prompt +attention, there are things you can do to make it easier for contributors to +reproduce and fix it. + +When you're reporting a bug, please help us understand the issue by providing, +to the best of your ability, + +* Clear, minimal steps to reproduce the issue, with as few non-Arrow + dependencies as possible. If there's a problem on reading a file, try to + provide as small of an example file as possible, or code to create one. + If your bug report says "it crashes trying to read my file, but I can't + share it with you," it's really hard for us to debug. +* Any relevant operating system, language, and library version information +* If it isn't obvious, clearly state the expected behavior and what actually + happened. + +If a developer can't get a failing unit test, they won't be able to know that +the issue has been identified, and they won't know when it has been fixed. +Try to anticipate the questions you might be asked by someone working to +understand the issue and provide those supporting details up front. + Review comment: I added a couple of links; feel free to add others if you have favorites ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
