toddfarmer commented on code in PR #13781:
URL: https://github.com/apache/arrow/pull/13781#discussion_r935876779
##########
docs/source/developers/bug_reports.rst:
##########
@@ -186,10 +176,109 @@ Good reproducible examples or minimal bug reports can be
found in next tabs:
#> 1 rows x 1 columns
#> $x <timestamp[ns]>
-
-Other resources:
+Other resources for producing useful bug reports:
* `Python: Craft Minimal Bug Reports by Matthew Rocklin
<https://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports>`_
* `R: Tidyverse: Make a reprex <https://www.tidyverse.org/help/#reprex>`_
* `R: Tidyverse's Reprex do's and don'ts
<https://reprex.tidyverse.org/articles/reprex-dos-and-donts.html>`_
* `Mozilla's bug-reporting guidelines
<https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>`_
+
+.. _identify-component:
+
+Identify Arrow component
+++++++++++++++++++++++++
+
+Arrow is an expansive project supporting many languages and organized into a
+number of components. Identifying the affected component(s) helps new issues
+get attention from appropriate contributors.
+
+* Use the **Component** field to indicate the area of the project that your
+ issue pertains to (for example "Python" or "C++").
+* Also prefix the issue title with the component name in brackets, for example
+ ``[Python] issue name`` ; this helps when navigating lists of open issues,
+ and it also makes our changelogs more readable. Most prefixes are exactly the
+ same as the **Component** name, with the following exceptions:
+
+ * **Component:** Continuous Integration — **Summary prefix:** [CI]
+ * **Component:** Developer Tools — **Summary prefix:** [Dev]
+ * **Component:** Documentation — **Summary prefix:** [Docs]
+
+.. _affected-version:
+
+Identify affected version
++++++++++++++++++++++++++
+
+If you're reporting something that used to work in a previous version
+but doesn't work in the current release, you can add the **Affects version**
+field to identify the earliest known version where the bug is observed.
+For feature requests and other proposals, leave **Affects version** empty as
+it is not applicable.
+
+.. _issue-lifecycle:
+
+Issue lifecycle
+===============
+
+Both bug reports and feature requests follow a defined lifecycle. The issue
+**Status** field is used to document the current state of the issue, while the
+**Resolution** field indicates the outcome of issues that have reached
+terminal status.
+
+
+.. _issue-status:
+
+Issue Status
+++++++++++++
+
+The Arrow project uses the following statuses in Jira to indicate what has -
+and will be - done on an issue:
+
+* **Open** - This is the initial issue state, prior to a contributor assigning
+ the issue and starting progress. Issues in this state should be unassigned.
+* **In progress** - At the time a contributor self-assigns an issue, the status
+ should be set to In progress by clicking the **Start progress** button. All
+ issues in this status should have an assignee - unassigned issues will be
Review Comment:
**_NOTE_**: This details a newly proposed project policy - that any issues
that have a status of "In Progress" but lack an assignee should be reverted to
"Open" status. This prevents issues from being misrepresented as "In Progress"
when there is nobody actually working the issue. This is likely to be
automated, and while manual inspection of an issue in such a state may indicate
somebody is likely working the issue (e.g., adding comments, etc.) but
neglected (or cannot) self-assign, that may not be recognized in an automated
process. Any automation should include a comment when changing the status from
"In Progress" to "Open" for this reason, guiding any affected users on how to
self-assign if appropriate.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
