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

[josephperrott]

No description provided.

[gkalpak]

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?

[gkalpak]

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

[josephperrott]

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.

[gkalpak]

Typo: an an

[josephperrott]

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]

I think this belongs in /docs/

[josephperrott]

Moved, as discussed offline.

[gkalpak]

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.

[josephperrott]

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

[josephperrott]

Updated to be more explicit that both must be true.

[jelbourn]

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.

[jelbourn]

I could also see adding a section like

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

[josephperrott]

Updated

[gkalpak]

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]

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]

@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]

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

[gkalpak]

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.

[josephperrott]

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.

[josephperrott]

Added the anchor

[gkalpak]

@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 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]

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

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}