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

cwylie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-druid.git


The following commit(s) were added to refs/heads/master by this push:
     new 2d6d1c1  Add more exempt tags for stalebot; Make stalebot to close 
PRs/issues in 28 days rather than in 7/14 days (#8084)
2d6d1c1 is described below

commit 2d6d1c17a0cf0f494c6a691dbaed2da030a2eb9a
Author: Roman Leventov <[email protected]>
AuthorDate: Thu Jul 18 08:57:42 2019 +0300

    Add more exempt tags for stalebot; Make stalebot to close PRs/issues in 28 
days rather than in 7/14 days (#8084)
    
    * Add more exempt tags for stalebot; Make stalebot to close PRs/issues in 
21 days rather than in 7/14 days
    
    * Exempt labels only for issues, not PRs; Add 'Uncategorized problem 
report' tag
---
 .github/ISSUE_TEMPLATE/problem_report.md |  1 +
 .github/stale.yml                        | 74 +++++++++++++++++++++++++++-----
 dev/committer-instructions.md            | 50 ++++++++++-----------
 3 files changed, 91 insertions(+), 34 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/problem_report.md 
b/.github/ISSUE_TEMPLATE/problem_report.md
index 3ddb741..0ff91ae 100644
--- a/.github/ISSUE_TEMPLATE/problem_report.md
+++ b/.github/ISSUE_TEMPLATE/problem_report.md
@@ -2,6 +2,7 @@
 name: Problem Report
 about: A template for Druid problem reports
 title: ""
+labels: Uncategorized problem report
 assignees: ''
 
 ---
diff --git a/.github/stale.yml b/.github/stale.yml
index deb8ca7..0df9ab3 100644
--- a/.github/stale.yml
+++ b/.github/stale.yml
@@ -15,12 +15,6 @@
 
 # Configuration for probot-stale - https://github.com/probot/stale
 
-# Issues or Pull Requests with these labels will never be considered stale. 
Set to `[]` to disable
-exemptLabels:
-  - Security
-  - Bug
-  - Proposal
-
 exemptMilestones: true
 exemptProjects: true
 exemptAssignees: true
@@ -31,10 +25,10 @@ staleLabel: stale
 # Configuration settings that are specific to just 'issues' or 'pulls':
 pulls:
   daysUntilStale: 60
-  daysUntilClose: 7
+  daysUntilClose: 28
   markComment: >
     This pull request has been marked as stale due to 60 days of inactivity.
-    It will be closed in 1 week if no further activity occurs. If you think
+    It will be closed in 4 weeks if no further activity occurs. If you think
     that's incorrect or this pull request should instead be reviewed, please 
simply
     write any comment. Even if closed, you can still revive the PR at any time 
or
     discuss it on the [email protected] list.
@@ -45,12 +39,15 @@ pulls:
     This pull request/issue has been closed due to lack of activity. If you 
think that
     is incorrect, or the pull request requires review, you can revive the PR 
at any time.
 
+  # Unlike for issues, there are no exempt labels for PRs, apart from 
"Evergreen". This is
+  # to foster PR authors to complete their work.
+
 issues:
   daysUntilStale: 280
-  daysUntilClose: 14
+  daysUntilClose: 28
   markComment: >
     This issue has been marked as stale due to 280 days of inactivity.
-    It will be closed in 2 weeks if no further activity occurs. If this issue 
is still
+    It will be closed in 4 weeks if no further activity occurs. If this issue 
is still
     relevant, please simply write any comment. Even if closed, you can still 
revive the
     issue at any time or discuss it on the [email protected] list.
     Thank you for your contributions.
@@ -60,3 +57,60 @@ issues:
     This issue has been closed due to lack of activity. If you think that
     is incorrect, or the issue requires additional review, you can revive the 
issue at
     any time.
+
+  # Issues with these labels will never be considered stale.
+  # There are almost all labels listed here, except:
+  # Backport
+  # Difficulty - *: not used these days, old issues should be revised
+  # Discuss
+  # duplicate
+  # Feature/Change Description
+  # Feature
+  # Flaky test: tests tend to become less flaky in time, so these issues 
should be revised
+  # invalid
+  # Priority - *: not used these days, old issues should be revised
+  # Question
+  # Release Notes
+  # Uncategorized problem report: they tend to decline in importance with time
+  # WIP
+  # wontfix
+  exemptLabels:
+    - Security
+    - Bug
+    - Proposal
+    - Design Review
+    - Improvement
+    - Performance
+    - Refactoring
+    - Apache
+    - Area - Automation/Static Analysis
+    - Area - Batch Indexing
+    - Area - Cache
+    - Area - Deep Storage
+    - Area - Dependencies
+    - Area - Dependency Injection
+    - Area - Dev
+    - Area - Documentation
+    - Area - Extension
+    - Area - Kafka/Kinesis Indexing
+    - Area - Lookups
+    - Area - Metrics/Event Emitting
+    - Area - Null Handling
+    - Area - Operations
+    - Area - Query UI
+    - Area - Querying
+    - Area - Router
+    - Area - Segment Balancing/Coordination
+    - Area - Segment Format and Ser/De
+    - Area - SQL
+    - Area - Testing
+    - Area - Web Console
+    - Area - Zookeeper/Curator
+    - Compatibility
+    - Contributions Welcome
+    - Development Blocker
+    - Ease of Use
+    - Error handling
+    - HTTP
+    - Incompatible
+    - Stable API
diff --git a/dev/committer-instructions.md b/dev/committer-instructions.md
index c15ba19..4aaa92b 100644
--- a/dev/committer-instructions.md
+++ b/dev/committer-instructions.md
@@ -24,7 +24,7 @@ This document contains various instructions relevant for 
Druid committers.
 This checklist describes steps that every committer should take for their own 
issues and PRs and when they are the first
 committer who visits an issue or a PR authored by a non-committer.
 
-1. Add appropriate tags to the PR, in particular:
+1. Add appropriate labels to the PR, in particular:
 
    - [**`Design 
Review`**](https://github.com/apache/incubator-druid/labels/Design%20Review) - 
for changes that will be
    hard to undo after they appear in some Druid release, and/or changes that 
will have lasting consequences in the
@@ -40,7 +40,7 @@ committer who visits an issue or a PR authored by a 
non-committer.
      - Other major changes
   
      PRs that flesh out community standards, checklists, policies, and PRs 
that change issue and PR templates, in other
-     words, many of the PRs tagged `Area - Dev` should often be tagged `Design 
Review` as well.
+     words, many of the PRs labelled `Area - Dev` should often be labelled 
`Design Review` as well.
 
      The PR description should succinctly, but completely list all public API 
elements (`@PublicApi` or
      `@ExtensionPoint`), configuration options, emitted metric names, HTTP 
endpoint paths and parameters that are added
@@ -59,18 +59,18 @@ committer who visits an issue or a PR authored by a 
non-committer.
      needed), and the ability to roll back to at least the immediate prior 
Druid version. If a change makes either one
      of these impossible then it should be re-designed.
 
-     All `Incompatible` PRs should be tagged `Design Review` too, but not vice 
versa: some `Design Review` issues,
+     All `Incompatible` PRs should be labelled `Design Review` too, but not 
vice versa: some `Design Review` issues,
      proposals and PRs may not be `Incompatible`.
 
    - [**`Release 
Notes`**](https://github.com/apache/incubator-druid/labels/Release%20Notes) - 
for important changes
    that should be reflected in the next Druid’s version release notes. 
Critically, those are changes that require some
    server or query configuration changes made by Druid cluster operators to 
preserve the former cluster behaviour, i. e.
-   the majority of PRs tagged `Incompatible`. However, some `Incompatible` PRs 
may not need to be tagged
+   the majority of PRs labelled `Incompatible`. However, some `Incompatible` 
PRs may not need to be labelled
    `Release Notes`, e. g. PRs that only change some extension APIs, because 
when building extensions with the newer
    Druid version the incompatibility will be discovered anyway.
 
      Secondarily, PRs that add new features, improve performance or improve 
Druid cluster operation experience could
-     also be tagged `Release Notes` at your discretion.
+     also be labelled `Release Notes` at your discretion.
 
    - [**`Bug`**](https://github.com/apache/incubator-druid/labels/Bug) / 
[**`Security`**](
    https://github.com/apache/incubator-druid/labels/Security) / 
[**`Feature`**](
@@ -78,7 +78,7 @@ committer who visits an issue or a PR authored by a 
non-committer.
    https://github.com/apache/incubator-druid/labels/Performance) / 
[**`Refactoring`**](
    https://github.com/apache/incubator-druid/labels/Refactoring) / 
[**`Improvement`**](
    https://github.com/apache/incubator-druid/labels/Improvement) - can be used 
to distinguish between types of changes.
-   
[**`Compatibility`**](https://github.com/apache/incubator-druid/labels/Compatibility)
 tag also falls into this
+   
[**`Compatibility`**](https://github.com/apache/incubator-druid/labels/Compatibility)
 label also falls into this
    category, it's specifically for PRs that restore or improve compatibility 
with previous Druid versions if it was
    inadvertently broken, or for changes that ensure forward compatibility with 
future Druid versions, forseening specific
    changes that would otherwise break the compatibility.
@@ -87,11 +87,11 @@ committer who visits an issue or a PR authored by a 
non-committer.
    that need to be merged before some other PRs could even be published. 
`Development Blocker` PRs should be prioritized
    by reviewers, so that they could be merged as soon as possible, thus not 
blocking somebody's work.
 
-2. If you added some tags on the previous step, describe why did you do that, 
either in the PR description (if you are
-the author of the PR) or in a comment (if you have added tags to a PR 
submitted by someone else).
+2. If you added some labels on the previous step, describe why did you do 
that, either in the PR description (if you are
+the author of the PR) or in a comment (if you have added labels to a PR 
submitted by someone else).
 
-3. Consider adding one or several **`Area -`** tags to the PR or issue. 
Consider [creating a new `Area -` tag](
-#creating-a-new-tag-on-github) if none of the existing `Area` tags is 
applicable to the PR or issue.
+3. Consider adding one or several **`Area -`** labels to the PR or issue. 
Consider [creating a new `Area -` label](
+#creating-a-new-label-on-github) if none of the existing `Area` labels is 
applicable to the PR or issue.
 
    - [`Area - Automation/Static Analysis`](
    
https://github.com/apache/incubator-druid/labels/Area%20-%20Automation%2FStatic%20Analysis)
 - for any PRs and issues
@@ -102,13 +102,13 @@ the author of the PR) or in a comment (if you have added 
tags to a PR submitted
    - [`Area - 
Dev`](https://github.com/apache/incubator-druid/labels/Area%20-%20Dev) - for 
PRs and issues related to the
    project itself, such as adding developer's docs and checklists, Github 
issue and PR templates, Github-related issues.
    Don't use for PRs and issues related to CI problems: use either `Area - 
Testing` for problems with Travis or
-   `Area - Automation/Static Analysis` for problems with TeamCity. PRs with 
`Area - Dev` tag should usually change files
-   in `dev/` or `.github/` directories.
+   `Area - Automation/Static Analysis` for problems with TeamCity. PRs with 
`Area - Dev` label should usually change
+   files in `dev/` or `.github/` directories.
    - [`Area - 
Documentation`](https://github.com/apache/incubator-druid/labels/Area%20-%20Documentation)
 - for PRs and
    issues about Druid's documentation for users and cluster operators. Don't 
use for PRs and issues about the
    documentation of the Druid's development process itself: use `Area - Dev` 
for that purpose. Don't use for issues and
    PR regarding adding internal design documentation and specification to 
code, usually, in the form of Javadocs or
-   comments (there is no specialized tag for this).  
+   comments (there is no specialized label for this).  
    - [`Area - 
Lookups`](https://github.com/apache/incubator-druid/labels/Area%20-%20Lookups) 
- for PRs and issues
    related to Druid's Query Time Lookups (QTL) feature.
    - [`Area - Null 
Handling`](https://github.com/apache/incubator-druid/labels/Area%20-%20Null%20Handling)
 - for PRs and
@@ -124,12 +124,12 @@ the author of the PR) or in a comment (if you have added 
tags to a PR submitted
    - [`Area - Segment Balancing/Coordination`](
    
https://github.com/apache/incubator-druid/labels/Area%20-%20Segment%20Balancing%2FCoordination)
 - for PRs and issue
    related to the process of loading and dropping segments in Druid clusters 
according to specified *rules*, and
-   balancing segments between Historical nodes in clusters. Coordinator node 
is responsible for both processes. This tag
-   is not called "Area - Coordinator" because Coordinator has some other 
duties that are not covered by this tag, for
-   example, compacting segments.
+   balancing segments between Historical nodes in clusters. Coordinator node 
is responsible for both processes. This
+   label is not called "Area - Coordinator" because Coordinator has some other 
duties that are not covered by this
+   label, for example, compacting segments.
    - [`Area - 
Testing`](https://github.com/apache/incubator-druid/labels/Area%20-%20Testing) 
- use for any PRs and
    issues related to testing (including integration testing), Travis CI 
issues, and flaky tests. For flaky tests, also
-   add [`Flaky 
test`](https://github.com/apache/incubator-druid/labels/Flaky%20test) tag.
+   add [`Flaky 
test`](https://github.com/apache/incubator-druid/labels/Flaky%20test) label.
    - [`Area - 
Zookeeper/Curator`](https://github.com/apache/incubator-druid/labels/Area%20-%20Zookeeper%2FCurator)
 - for
    any PRs and issues related to ZooKeeper, Curator, and node discovery in 
Druid.
 
@@ -143,7 +143,7 @@ committed, to avoid cluttering the release manager's 
workflow.
 problems even if you don't plan to review the PR.
 
 6. If you create an issue that is relatively small and self-contained and you 
don't plan to work on it in the near
-future, consider tagging it [**`Contributions Welcome`**](
+future, consider labelling it [**`Contributions Welcome`**](
 https://github.com/apache/incubator-druid/labels/Contributions%20Welcome) so 
that other people know that the issue is
 free to pick up and is relatively easily doable even for those who are not 
very familiar with the codebase.
 
@@ -159,17 +159,19 @@ number (such as 0.10.1, while the previous release is 
0.10 or 0.10.0), rename th
 
 4. Consider thanking the author for contribution, especially a new contributor.
 
-## Creating a new tag on Github
+## Creating a new label on Github
 
-After creating a tag for your PR or issue, don't forget to take the following 
steps:
+After creating a new label for your PR or issue, don't forget to take the 
following steps:
 
-1. Search existing PRs and issues and try to add the new tag to at least three 
of them.
+1. Search existing PRs and issues and try to add the new label to at least 
three of them.
 
-2. Describe the new tag in the [PR and issue action item checklist for 
committers](
+2. Describe the new label in the [PR and issue action item checklist for 
committers](
 #pr-and-issue-action-item-checklist-for-committers) above.
 
-3. Although it is *not* necessary to preliminarily discuss creation of a new 
tag in the developers' mailing list, please
-announce the new tag after you've created it at `[email protected]`.
+3. Add the label to stalebot's excemptions if needed: see 
[`stale.yml`](../.github/stale.yml).
+
+4. Although it is *not* necessary to preliminarily discuss creation of a new 
label in the developers' mailing list,
+please announce the new label after you've created it at 
`[email protected]`.
 
 ## Become an Administrator of the Druid project in TeamCity
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to