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

Add issue templates for ReactPHP organisation #3

Merged
merged 1 commit into from
Nov 16, 2022

Conversation

SimonFrings
Copy link
Member

I recently proposed to add issue templates to all ReactPHP repositories, you can find the original discussion regarding this topic in reactphp/reactphp#466. By the time I thought it would be the best way to manually add them to most of the ReactPHP repos for the following reason (full conversation):

The downside is that EVERY project inside the ReactPHP organisation gets the same issue template. This may make sense for most projects (like dns, http, etc.) but not for something like reactphp/branding or reactphp/reactphp. I would instantly do this if GitHub had some kind of functionality to exclude specific repositories, but I didn't find anything similar.

So we decided to introduce issue templates the way I proposed it and I started opening up pull requests in some ReactPHP repositories e.g. reactphp/reactphp#466, reactphp/http#475 which have already been merged. There are still repositories missing these changes.

I started talking with @clue about this and noticed that it should be possible to open up blank issues, which I disabled in my recently submitted pull requests. This means I have to open up a second pull request in every repository which already supports issue templates. The same goes for every future adjustments, seems a bit overkill to open more than 10 pull requests for this, right?

On a second thought it would be more wise to add issue templates on an organisational level, to keep future adjustments for these templates rather small and simple. Yes, repositories like reactphp/branding will also receive those templates, but how big of a deal is it anyway.

If we decide to go this path, we'd laso have to revert my already merged pull request. This will seem a little strange to the outside and is why I provide all this information in here, so people might understand our behavior.

@WyriHaximus and @clue, what do you think?

@clue clue added the documentation Improvements or additions to documentation label Nov 8, 2022
@clue
Copy link
Member

clue commented Nov 8, 2022

@SimonFrings This sounds like a reasonable suggestion and I agree that it makes sense to reconsider the decision made in reactphp/reactphp#466. I'm 👍 on this provided we revert the changes done in the component repositories.

You've also mentioned enabling blank issues, do you plan to create a separate follow-up PR or should this be part of this PR?

@SimonFrings
Copy link
Member Author

@clue This is already part of this PR. I have actively disabled blank issues in my other PRs by adding the following line to the config.yml:

blank_issues_enabled: false

Blank issues are automatically enabled by GitHub if I don't use this option.

Copy link
Member

@clue clue left a comment

Choose a reason for hiding this comment

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

@SimonFrings Thanks for the looking into this and for the confirmation, changes LGTM! :shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants