Skip to content

Conversation

@NovemberTang
Copy link
Contributor

@NovemberTang NovemberTang commented Aug 13, 2025

What is being recommended?

  • Adds interactive as a valid status topic
  • Remove recommendations that were added to highlight the deprecation of repo-genesis, as this happened two years ago and is less relevant today
  • Clarify documentation about repository visibility, and remove an unrecommended approach.

What's the context?

Since we are now tracking the number of repos that don't have a production status, I'm updating the recommendations on how to classify repos.

While I'm here, I've updated some other parts of the docs that are confusing or less relevant.

With the upcoming security training, it's now more important that this information is up-to-date.

By default, new repositories are open to the department via `Internal` visibility (for read access).

(Existing `Private` repositories may achieve the same effect by additionally granting read access to [`@guardian/guardian-developers-read`][gh-read]. This approach is not recommended since GitHub's introduction of `Internal` visibility.)
(Existing `Private` repositories may be converted to `Internal` if their contents is not particularly sensitive)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we not leave in the bit about granting read access on private repos, for those who can't convert to 'internal'?

Copy link
Contributor Author

@NovemberTang NovemberTang Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't really considered this! Are there scenarios where it's not possible to convert a repo to from private to internal?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I was just going by the bit where it says "if their contents is not particularly sensitive" - I guess I mean the scenarios when the contents are particularly sensitive? If we don't think there are any contexts like that, maybe we could remove that caveat?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants