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

Centralize Issue and Pull Request templates for (most) repos to the .github repo #286

Open
Asartea opened this issue Jul 6, 2023 · 3 comments

Comments

@Asartea
Copy link
Contributor

Asartea commented Jul 6, 2023

Title Author Date
Centralize Issue and Pull Request templates Asartea 2023-06-07

Centralize Issue and Pull Request templates for (most) repos to the .github repo

Summary

In order to decrease the amount of maintenance required to update Issue/Pull Request templates and lower the risk of those falling behind/diverging from each other we should centralize most of them to TheOdinProject/.github.

Motivation

While working on TheOdinProject/theodinproject#3901 I noticed that a lot of TOP's repos have (almost) identical .github/ folders, containing almost the exact same files (I'm going to guess they were originally copy/pasted when creating new repos). This adds a huge maintenance burden when making any changes to the contents of these files, as individual PR's have to be filed against each repo.

Centralizing these to a single source of truth which then propagates down to the individual repos would make this a lot easier, as changes would instead only require changing a single set of files.

Suggested implementation

GitHub includes a feature for default community health files, which are files in certain directories of the .github repo of an organization. These files are automatically used and displayed by GitHub for any repos that don't have a local equivalent. TheOdinProject/.github already includes a set of default templates, and I have had a WIP PR for Pull Requests and a config for a while. Once we are happy with the contents of those files we can simply drop the files from each repo we want to use them in, and it ought to just work:tm:.

One additional thing to consider would be labels; we can define labels that will be used in each template, and GitHub lets a org define default labels any project will include, but it is my understanding that TOP is looking to slim down on the amount used, so there is a question which (if any) should be included

Drawbacks

  • Because there is a single set of files, they cannot be customized. For some repos I think this is a deal breaker (theodinproject, curriculum, this one, odin-bot-v2), but for some others there is a decision to be made if the added content is worth the maintenance (some of the exercise repos have a added note about the solutions in their pull request template as an example)
  • It becomes less clear to a new contributor how these files are defined, and downloads/clones don't include them; this could make it harder to contribute to them

Alternatives

Are there any alternative implementations to this? What else can be done?

Additional

Originally brought this up at https://discord.com/channels/505093832157691914/1124433492273545316/1126149422313648199

@rlmoser99
Copy link
Member

It is a good idea to centralize what we can, but I do not think we can use one PULL_REQUEST_TEMPLATE.md for all of the repositories.

I've recently worked on updating them and a lot of the checkboxes under Pull Request Requirements are different on each of the repos. For example, the suggested title of the PR is different on a lot of the repos. On the main site, we ask for tests to be written for new features. On exercise repos we also ask for solutions to be updated.

If we consolidated them, we would need a lot of checkboxes with wording like "If applicable..." and I think contributors would get lost on knowing if it is applicable.

@Asartea
Copy link
Contributor Author

Asartea commented Jul 6, 2023

I've recently worked on updating them and a lot of the checkboxes under Pull Request Requirements are different on each of the repos.

Yeah I just looked and they diverge a lot more than I remember; that probably puts a PR template out of the question then (mostly caused by all of the exercise repo's have you included the <insert solution variant> in your changes)

@Asartea
Copy link
Contributor Author

Asartea commented Jul 10, 2023

So I had some free time today, and came up with this. yes means that the file matched the standard file, when comparing against the ones in theodinproject repo, as I assume thats where they got copied from. Almost none of the PR templates match; except for one minor difference most of issue templates do match (also if someone has the free time to check my work I'd greatly appreciate it; I think I got them all correct but its entirely possible I missed something)

Repo Is there a PR template? PR Is there a Issues folder? feature_request bug_report
curriculum yes no yes no no
theodinproject yes no yes yes yes
top-meta no N/A yes no no
odin-bot-v2 yes no yes no yes
react-examples yes no yes yes** yes**
javascript-exercises yes no yes yes** yes**
css-exercises yes no yes yes** yes**
ruby_testing yes no yes yes** yes**
blog yes no* no N/A N/A
ruby-exercises yes no yes yes** yes**
custom_enumerable_project yes yes no N/A N/A
.github***          

* Only contains note on spellchecker; set up code-spell?
** Only difference is the example location****; can probably be dropped as long as the checkbox remains?
*** N/A: Intended Default

**** By this I mean that they contain some variation on the following line - [ ] The title of this issue follows the location for request: brief description of request format, e.g. <repo specific location>: <sometimes repo specific example. This is the only piece of information I think could be safely dropped by generalizing to just - [ ] The title of this issue follows the location for request: brief description of request format

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

No branches or pull requests

2 participants