Should we disable issues on "implementation" buildpack repos?

[kvedurmu]

I've been wondering if we should disable github issues on "implementation" buildpack repos and direct all users to file issues on the "meta" language family buildpack repo. For example, issues/requests around the bundler, MRI, bundle-install, etc. would all get filed in the Ruby buildpack repo.

I could think of a couple advantages of doing something like this:

• New users/contributors only need to go to a single repo for each language family to file relevant issues (individual language family repos are already linked in the Paketo docs). As a new user/contributor, it can be difficult to know what repo to file issues in, especially if I don't understand how the Paketo buildpack is structured.
• We can create a central Github projects board that the Paketo core development team can use as a sort of "backlog" (language family maintainers could also create project boards for their respective language). This would serve in providing the community better visibility into what the core team is working on (and what issues are coming up next that can be picked up). Last I checked, Github projects has a 25 repo limit; there are over 100+ Paketo repos so we've never been able to use this.
• Easier for language family maintainers to triage issues (???). I don't know much about this one, but just guessing.

Really curious to hear what other folks think about this.

[ForestEckhardt]

Just some food for thought. I don't know that there is a way to link pull request from one repo to issues for another in such a way that it would cause the issue to close when the PR was merged. This is a feature we try and utilize in order to keep a handle on the issues themselves.

[fg-j]

I agree that it's probably a better UX to look in one place for everything related to a given "metabuildpack". According to the Github docs, we can still link issues across repositories if we use the keyword syntax.

Something like: Resolves paketo-buildpacks/ruby#404 would close that issue on merge regardless of where the issue lives. This would require a bit more discipline on our part to make sure we're consistently linking issues, but that's a problem we are already facing.

[fg-j]

Perhaps we should add a checkbox to our PR template for "Here's the linked issue(s) that this PR will close"

[sophiewigmore]

I'm curious to hear what others think about this. I'm kind of torn I like the idea of having a central board as a backlog, and lessening the confusion for users about where issues should be filed.

One nice thing about filing issues on the specific implementation buildpack repo is that it invites users to take a look at that specific buildpack. When filing an issue, it can be illuminating to actually go to the repo and check out the specific buildpack that's at the root of the issue. My concern is if we move away from filing implementation buildpack issues on their repos, some of this ease of getting context will be lost, if that makes sense. I don't know. Maybe I'm overestimating the number of people who do this

[ryanmoran]

I have questions and concerns about this. Let me address each point:

New users/contributors only need to go to a single repo for each language family to file relevant issues (individual language family repos are already linked in the Paketo docs). As a new user/contributor, it can be difficult to know what repo to file issues in, especially if I don't understand how the Paketo buildpack is structured.

Do we have evidence that this is true? As it exists today, there is nothing stopping a user that didn't know where to file a Ruby related issue from opening that issue in the top-level Ruby repo. When the issue gets triaged, we usually have been able to move it to the appropriate place with no burden on the end-user to understand that beforehand.

We can create a central Github projects board that the Paketo core development team can use as a sort of "backlog" (language family maintainers could also create project boards for their respective language). This would serve in providing the community better visibility into what the core team is working on (and what issues are coming up next that can be picked up). Last I checked, Github projects has a 25 repo limit; there are over 100+ Paketo repos so we've never been able to use this.

We can already do this. I've been running a "shadow" backlog as a private project for a while now. The 25 repo limit is just on the number of repos you can "link" to the project. Linking repos is really just a convenience mechanism to make it just a little bit easier to add issues to the project, but not necessary. The biggest hurdle we face in using GitHub projects is that we track stuff that is outside of the Paketo project in our current backlog solution. Even if we did this, we'd need somewhere to also track all of this other work.

Easier for language family maintainers to triage issues (???). I don't know much about this one, but just guessing.

I can't speak for everyone, but this isn't an issue I am having.

I also just have a general concern with us disabling issues on our repos. If you were a user that knew a bug existed in the go-mod-vendor repo, but couldn't file an issue there, is that a worse experience?