Should we use the discussions for feature request/design decision?

[elizabetdev]

Hello 👋 ,

The GitHub Discussions is in a limited public beta and the EUI repo was flagged into the beta so we can test things out.

I converted a few issues into discussions so we can see how it looks like. There's a way to convert a specific label into a discussion category but I think is better if we try this GitHub beta functionality first.

For now, we have the following categories (feel free to add and/or suggest more):

1. The idea is that we test and if we all agree we can convert the rest of the design decision and feature request issues into discussions.

2. I'm also not completely sure if we should have two categories: design decision and feature request. What do you think? Would only feature request work? 🤔

3. If we all agree what should be our flow from here? We discuss and then if we agree on a decision we open an issue?

[myasonik]

I like the idea of moving the occasional community question that EUI gets into here, just, organizationally... Like, I know we've gotten a couple like "how do I best do X?" and seems perfect for the Q&A label here.

I'm not sure I like moving feature requests into here though but maybe only because I'm not familiar with discussions. But because feature requests usually get resolved with a PR and then the discussion/issue is closed, it seems best for an issue. Though, maybe feature requests should start here and then an issue can be created for a discussion once there's a spec or something along those lines?

[chandlerprall]

In a world where EUI uses the new Discussions, some of those would have been created as a discussion first while others would still have been filed as an issue and then converted over. While you can move Issue->Discussion it doesn't look like you can convert a discussion back to an issue - though you can always create a new issue from any comment.

I do like the distinction between closable and answerable. There have been instances when trying to figure out why a change was made where many related issues have to be navigated and it isn't apparent which part of the thread was the final decision - having specifically-selected answers would help.

I tested referencing a discussion from a PR - the issue short code (#0000) turns into a link but GH does not show the PR's mention within discussion thread, and you cannot further associate them (e.g. "Fixes #0000").

---

Looking through issues marked with the discussion label I see some groupings:

• We might need to develop a pattern around something [EuiTabs] Often misused in Kibana as navigation #4200
• Feature request that isn't immediately accepted (I think this is most of them) [EuiInMemoryTable] Request ability to preserve selection when changing page #4090
• Kinda a combination of the previous two items, broader patterns implemented across many components [Meta][EuiTooltip] Flexibility, accessibility & guidelines #4040
• Explorations [EuiDragDrop] Inefficiencies for specific use-case #4024
• Proposals [EuiSelectable] Discoverability of exclusions #3625

---

Two grey areas IMO:
1. issues that identify a need for a broader discussion before addressing the issue

Is this handled inline in the Issue or jump into a separate Discussion?

2. items requiring a decision rather than discussion

We like to crowd source opinions, use cases, etc, and try to find a consensus that helps us move forward. Often, these conversations are less discussion and more info/requirements gathering so that the issue owner can act.

---

But because feature requests usually get resolved with a PR and then the discussion/issue is closed, it seems best for an issue. Though, maybe feature requests should start here and then an issue can be created for a discussion once there's a spec or something along those lines?

I think that would be the right way - start proposed features as a discussion and when an answer is reached we create a separate issue with the spec.