You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@arrow.apache.org by do...@apache.org on 2022/12/09 15:18:35 UTC

[arrow] branch dom/jira-gh created (now b3ff049f0b)

This is an automated email from the ASF dual-hosted git repository.

domoritz pushed a change to branch dom/jira-gh
in repository https://gitbox.apache.org/repos/asf/arrow.git


      at b3ff049f0b MINOR: Update reviewing instructions to talk about issues instead of Jiras

This branch includes the following new commits:

     new b3ff049f0b MINOR: Update reviewing instructions to talk about issues instead of Jiras

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.



[arrow] 01/01: MINOR: Update reviewing instructions to talk about issues instead of Jiras

Posted by do...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

domoritz pushed a commit to branch dom/jira-gh
in repository https://gitbox.apache.org/repos/asf/arrow.git

commit b3ff049f0b0b52ceee98598c4ab7fe0cd9be9871
Author: Dominik Moritz <do...@gmail.com>
AuthorDate: Fri Dec 9 10:18:27 2022 -0500

    MINOR: Update reviewing instructions to talk about issues instead of Jiras
---
 docs/source/developers/reviewing.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/source/developers/reviewing.rst b/docs/source/developers/reviewing.rst
index 3b03693117..a453397c1b 100644
--- a/docs/source/developers/reviewing.rst
+++ b/docs/source/developers/reviewing.rst
@@ -57,7 +57,7 @@ Scope and completeness
   confused if they hit problems introduced by a merged PR.
 
 * What changes are in-scope for a PR and what changes might/could/should be
-  pushed out of scope and have a follow-up JIRA created should be determined
+  pushed out of scope and have a follow-up issue created should be determined
   in collaboration between the authors and the reviewers.
 
 * When a large piece of functionality is being contributed and it seems
@@ -70,7 +70,8 @@ Scope and completeness
 Public API design
 -----------------
 
-* Public APIs should nudge users towards the most desirable constructs.
+* Public APIs should nudge users towards the mo
+st desirable constructs.
   In other words, if there is a "best" way to do something, it should
   ideally also be the most easily discoverable and the most concise to type.
   For example, safe APIs should be featured more prominently than