New issue templates for contribution

[selenehinkley]

Documenting @alex-page, @heyjoethomas and @chloerice's conversation about better issue templates for new icons, component bugs, and documentation. We will use this as the place to continue the conversation and refer back to it when we kick off a fast-follow contribution project after we ship the MVP contribution documentation.

Alex Page
@polaris-enablement one thing I am craving is better issue templates for new icons, component bugs, and documentation. Now that the repos are more centralised this could evolve to better categorise and serve our needs.

Chloe Rice:hungrypachi: 3 hours ago
Def in the works!! JJ and I were just talking about the fact that the idea of a "feature request" is no longer relevant or viable, we need to cultivate a culture of contribution not requests.

Alex Page 3 hours ago
Yeah I want to re-open all feature request issues and only close ones that are implemented.

Alex Page 3 hours ago
I have zero visibility into them when they are closed.

Joe Thomas 3 hours ago
Could easily tie these into the docs as well on the contribution pages being built. Would be really nice if those things aligned so folks feel confident they are selecting the right Issue type.

Alex Page 3 hours ago
This could be a mini CMS for proposing icons as well. They really made issue templates super powerful now.
https://github.com/micromark/micromark/issues/new?assignees=&labels=&template=1-bug.yml (edited)

Chloe Rice:hungrypachi: 3 hours ago
The whole concept of requesting a feature is no longer viable. Our team and the work we produce (resources we provide and own) have expanded far beyond the component library. In my opinion, all feature requests need to remain closed and our templates and contribution guidelines need to be framed toward contributing fixes and features (see a bug or gap, fix or fill it), not reporting and requesting (hands off, ask and wait).

Alex Page 3 hours ago
I disagree with that. I still want to know what features people need. We have no responsibility to make them or address their request. I do think it’s important to know the Rich Text Editor has 140+ thumbs up as a feature request.

Chloe Rice:hungrypachi: 3 hours ago
I'd propose we frame that as a wish list, which could be an interactive page on the style guide, not as an issue template creating noise and making it difficult to track the health of the repo.

Chloe Rice:hungrypachi: 3 hours ago
^And tie it into an incentive program (along with bug fixes), which I think we need to make contribution fun and reward the work that folk put into keep the system healthy and evolving.

Alex Page 3 hours ago
I understand what you mean @chloerice. It’s pretty easy to remove a label to get an indicator of health when the issues are organised. I think we see the “issues” tab as two different things. For me it’s documentation for what consumers need fixed, want better and would like to see in the future. I have zero concerns with there being 1000 issues opened.
I do think it’s important to be able to, at a glance understand the health of the repo and address problems. I don’t think we are there today. (edited)

Chloe Rice:hungrypachi: 3 hours ago
For me it makes it difficult to filter the noise in the abyss of issues and PRs that we don't have fine-grained control over getting notifications for. If GitHub allowed us to follow and group notifications based on Label (and maybe they do?!) I feel like it would be less overwhelming to make sure externally submitted issues don't fall through the cracks among all the noise.

Alex Page 3 hours ago
I hear you. I also see our teams roadmap and features we are building documented in issues. It doesn’t make sense to me to close everyone else’s requests and leave ours open.
There is of course a difference between when we are actively working on something versus documenting work to be done. (edited)

Chloe Rice:hungrypachi: 3 hours ago
Honestly, what I really want to do is build a control center that pulls from and posts to GitHub and the other channels and centralizes the state and maintenance of the system (in a highly aesthetic and strategic way lol). (edited)
:nod2:

Alex Page 3 hours ago
I would use GitHub and project boards to do that. With good labeling (from updated issue templates) we could easily do this.

Chloe Rice:hungrypachi: 3 hours ago
Yeah I used to use GitHub project boards for managing the Feature Requests and Bug reports back in the day, but I was the only one maintaining them 🥲

Chloe Rice:hungrypachi: 3 hours ago
(and they're not pretty :troll-blob:) (edited)

Chloe Rice:hungrypachi: 3 hours ago
To be fair, with the new GitHub Projects issues are auto-added, so not really the same maintenance level anymore 🙌:skin-tone-4:

Alex Page 3 hours ago
Yes. We can celebrate by throwing my once useful GitHub action in the bin lol 🎉

Chloe Rice:hungrypachi: 3 hours ago
(more context on the convo Enablement blobby had earlier https://shopify.slack.com/archives/C03GDPRE25D/p1654273787427209)

Alex Page 3 hours ago
You are already 10 steps ahead of me. I love it! (edited)