Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: create Issue and Pull Request markdown doc, explaining automatic locking policy #32405

Closed
wants to merge 1 commit into from

Conversation

@josephperrott
Copy link
Member

commented Aug 29, 2019

No description provided.

@josephperrott josephperrott requested a review from StephenFluin Aug 29, 2019

@josephperrott josephperrott requested a review from angular/fw-dev-infra as a code owner Aug 29, 2019

@googlebot googlebot added the cla: yes label Aug 29, 2019

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from b3b8f72 to c19fb67 Aug 29, 2019

@gkalpak
Copy link
Member

left a comment

The file name is too generic. Do we have to have a specific name for it to be picked up or is it up to us?
Also, could we move it in a subdirectory?

Inactive issues and pull requests in Angular repos are automatically locked after 30 days.

Issues and pull requests are locked based on the following criteria:
- In a closed or merged state

This comment has been minimized.

Copy link
@gkalpak

gkalpak Aug 29, 2019

Member

This sounds confusing. Does this mean that closed/merged issues will be locked (and no more comments will be allowed)?

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 29, 2019

Author Member

After 30 days of no activity on the closed/merged pr, yes.

Though now that I reread this it is redundant as a merging a PR closes it, so a merged PR is closed. Updated.

Automatically locking inactive issues and pull requests allows for Angular's project maintainers to prioritize and focus on active work in our projects.

#### I want to comment on an issue/pull request that was locked, what should I do?
When an an issue has been closed and inactive for over 30 days, the original context has likely become outdated. If you are encountering a similar or related issue in the current version, please open a new issue and provide up-to-date reproduction instructions.

This comment has been minimized.

Copy link
@gkalpak

gkalpak Aug 29, 2019

Member

Typo: an an

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from c19fb67 to 90a93e9 Aug 29, 2019

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

The name is intentionally generic as it will be a location where we can explain our Github Processes for pull requests and issues. As we do more to automate the lifecycle of issues/prs in our repos.

The intention of having it at the base of the repo is that we will be linking to it when we auto lock issues so we want to have the "prettiest" URL possible. Additionally, it is a org wide policy so other repos from the Angular org will link to it as well. That is the idea at least.

@StephenFluin

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

I think this belongs in /docs/

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

Moved, as discussed offline.

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from 90a93e9 to 3437d39 Aug 29, 2019

@josephperrott josephperrott requested a review from IgorMinar as a code owner Aug 29, 2019

Inactive issues and pull requests in Angular repos are automatically locked after 30 days.

Issues and pull requests are locked based on the following criteria:
- In a closed state

This comment has been minimized.

Copy link
@gkalpak

gkalpak Aug 29, 2019

Member

I still find this confusing 😁

My understanding is that we are going to lock all issues that have no activity for 30 days or more. If my understanding is correct, then this bullet point is redundant (since the second bullet point covers both open and closed issues) and having it here makes it sound as if we are locking closed issues immediately.

If the idea is to only lock closed issues (that additionally do not have any activity for 30 days or more), then I would make it explicit that both criteria must be met for an issue to be closed.

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 29, 2019

Author Member

The idea is to only lock closed issues. We do not want to automatically lock open issues.

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 29, 2019

Author Member

Updated to be more explicit that both must be true.

This comment has been minimized.

Copy link
@jelbourn

jelbourn Aug 29, 2019

Member

I would just eliminate this second bit and update the first sentence to highlight the "Closed" part. Also I accidentally edited the rest:

# Automatic conversation locking
Closed issues and pull requests are locked automatically after 30 days of inactivity. 

## I want to comment on a locked conversation, what should I do?
When an issue has been closed and inactive for over 30 days, the original context is likely outdated.
If you encounter a similar or related issue in the current version, please open a new issue and
provide up-to-date reproduction instructions.

## Why lock conversations?
Automatically locking closed, inactive issues guides people towards filing new issues with updated
context rather than commenting on a "resolved" issue that contains out-of-date or unrelated
information. As an example, someone may comment "I'm still having this issue", but without
providing any of the additional information the team needs to investigate.

## Who do you think you are?
I'm Batman.

Okay, maybe not that last part.

This comment has been minimized.

Copy link
@jelbourn

jelbourn Aug 29, 2019

Member

I could also see adding a section like

## What counts as activity?
Any comment counts as activity. Reactions do not count as activity.

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 30, 2019

Author Member

Updated

@gkalpak

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

BTW, regarding the file name and the URL pointing to the file:

  1. GitHub comments support Markdown links, so we can decouple the file name from the URL text 😉
    (E-mail notifications would still show the long URL, but I think it is much of a problem.)

  2. I would recommend linking to the file on a specific commit, instead of on master. Linking to files on master runs the risk of breaking the links when the file is moved or changed in the future (if you are linking to a specific section). Also, linking to a specific commit ensures that the content of the linked file reflects the policy based on which the issue was closed.

Generally, getting from an old file version to the latest version is fairly easy, when the file is at the same location on master. But going from a broken link to the version of the file at the point at which the comment was posted is not that straight forward.

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

Good call on linking to the file, we will need to be sure to do that. That will occur in angular/dev-infra#28

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from 3437d39 to 7b7efba Aug 29, 2019

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

@gkalpak do you a suggestion for the file naming? I think the file naming makes sense for the overall usage of the file long term, but am open to other options.

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from 7b7efba to 2d525e5 Aug 29, 2019

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2019

cc @jelbourn to weigh in on wording of the markdown file

@josephperrott josephperrott requested a review from jelbourn Aug 29, 2019

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from 2d525e5 to 134b39d Aug 30, 2019

@@ -0,0 +1,13 @@
# Automatic conversation locking

This comment has been minimized.

Copy link
@gkalpak

gkalpak Aug 30, 2019

Member

If the plan is for this document to expand in the future and contain more sections (on things other than converstation locking), then I assume we would link to specific section (not the file as a whole):

[converstation locking](https://github.com/.../docs/GITHUB_PROCESS.md#automatic-conversation-locking)

GitHub will automatically create anchors for headings, based on the heading text. This is hanydy, but it means that the comment template needs to be updated every time we tweak the heading.

If linking to specific section is indeed the intention, a better alternative is to use explicit anchor (which are independent of the heading text); e.g.:

<a name="conversation-locking"></a>
# Automatic conversation locking

This way, we can link to ...GITHUB_PROCESS.md#conversation-locking and the link will still work if the heading text modified later.

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 30, 2019

Author Member

Yes, we would be linking to the specific section. Though we shouldn't have to change the heading title, or at least not too often.

This comment has been minimized.

Copy link
@josephperrott

josephperrott Aug 30, 2019

Author Member

Added the anchor

@josephperrott josephperrott force-pushed the josephperrott:issue-pr-locking branch from 134b39d to 3707f9b Aug 30, 2019

@gkalpak

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

@gkalpak do you a suggestion for the file naming?

I am not 100% clear on what the file is going to be used long term (and I am not good with names anyway 😛), but GITHUB_PROCESS sounds fine.

I could also see a name with "maintenance" and "policies", but that could get long (and "policies" makes it sound formal).

@josephperrott

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2019

This PR got marked as needing @IgorMinar for approval because it did not fit into any of the CODEOWNERS rules, but it falls under dev-infra and dev-rel as best as I can tell

@matsko matsko closed this in ad13520 Aug 30, 2019

@matsko matsko reopened this Aug 30, 2019

@matsko

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

Sorry, I submitted this PR prematurely thinking it was ready, but we still need @IgorMinar to review.

matsko added a commit that referenced this pull request Aug 30, 2019
revert: docs: create Issue and Pull Request markdown doc, explaining …
…automatic locking policy (#32405)

This reverts commit ad13520.

@matsko matsko closed this in 67d80f9 Aug 30, 2019

sabeersulaiman added a commit to sabeersulaiman/angular that referenced this pull request Sep 6, 2019
sabeersulaiman added a commit to sabeersulaiman/angular that referenced this pull request Sep 6, 2019
sabeersulaiman added a commit to sabeersulaiman/angular that referenced this pull request Sep 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.