semi-threaded "discussions" do not add enough benefit to justify moving from "issues"
Opened this issue · 6 comments
sighs Stupid half-done github discussions UI doesn't have a mouseover explanation of the little up-arrow beside the title, which suggests there's something preceding this page ... but no, it's some kind of rating or voting system, which only allows an up-vote and doesn't let you UNDO a click (so there's at least one accidental up-vote from me), nor down-vote as should always be possible where there are up-votes.
And this is a (meta-)comment, not an answer, but there's no way to add a comment on the question, because github hasn't learned from other discussion and/or q&a sites.
I do not think semi-threaded "discussions" add enough benefit to justify moving from "issues".
Originally posted by @TallTed (me) in #225 (comment)
I agree with @TallTed and additionally, I think that having all the topics in one place is a plus.
There is a UI feature to transform discussions into issues.
@bblfish and @elf-pavlik if you agree with this, could you transform the discussions you created into issues and once this is done, let's disable discussions for this repo.
Actually we were discussing issues vs. discussions in some panels. I think using them in combination can be very helpful, I think we could adopt following approach:
Issues
They should have clear acceptance criteria stated in them and we need a clear path to resolving them via pull request. Preferably they should include (possibly after initial conversation) target document which we would amend in PR. Of course sometimes we need to create new document.
Discussions
More liberal space to exchange ideas and thoughts. We all should be engaging in them and following up but we don't need to resolve them.
Currently we have 90 issues open in this repository and I'm afraid this number will only grow unless we take systematic approach of processing and resolving them. Having mixed bag of issues which we can resolve and open ended conversations IMO only makes it harder to establish such systematic approach.
I agree with @TallTed and additionally, I think that having all the topics in one place is a plus.
We still have Issues in Discussions in the same repository. The difference is in how we process them.
I think @elf-pavlik's thoughts of how to use these two spaces within this repo are far more idealized than the reality in which we live. Further, I think that the not-quite-thought-out and still evolving functionality (especially but not only regarding sub-threading; also including the wannabe-reddit "up-without-down ranking") of the Discussions "feature" itself is problematic.
IMO, trying to allocate issues (as historically used) between Issues and Discussions is just going to lead to endless, er, discussion about which arena is appropriate for a given, ahem, issue, and quite possibly to repeated moves of one thread from one space to the other and back and forth and back....
Ultimately, I'm not the decision maker, and recognizing that, I'm not taking any actions that would reflect such decision. I am less than happy about others who are also not the decision maker prematurely taking such actions, which are, to my mind, likely to lead to a fait accompli.
We could tag "issues" as discussions, so that when we get round to count what needs to be resolved we don't count those open ended ones. That would give us a better feel that we are making progress.
Ultimately, I'm not the decision maker, and recognizing that, I'm not taking any actions that would reflect such decision.
I think creating dedicated repository for each draft, as we consider doing for solid-oidc, would make this more straight forward. In that case editors of given draft can decide on the workflow which suits moving the draft forward. Panel repo would become de facto a discussion board where we wouldn't have to commit to actually resolve any open issues.
It would also make clear that editors are responsible for making progress on resolving issues on their draft.
IMO, trying to allocate issues (as historically used) between Issues and Discussions is just going to lead to endless, er, discussion about which arena is appropriate for a given, ahem, issue, and quite possibly to repeated moves of one thread from one space to the other and back and forth and back....
What problem do you see with drawing that line based on: having (or not) clear (actionable) acceptance criteria for resolving the issue?
I think creating dedicated repository for each draft, as we consider doing for solid-oidc
github.com/solid already has 148 repos. While each of these is fine once you're plugged into it, Github does not provide good UI/UX for navigating among them, among other challenges. Rapidly increasing their number does not seem to me like a recipe for success.
On the other hand, dedicated branches for each draft might make sense, though preventing those from becoming forks can also pose a challenge in a large and/or dispersed dev team, such as Solid's.
What problem do you see with drawing that line based on: having (or not) clear (actionable) acceptance criteria for resolving the issue?
Simply, that would put many issues in which I have an interest into Discussions, which UX and "threading" I have found do not work well for me. I would be forced to use a poor imitation of a threaded discussion space, or not deliver my input (and possibly not digest contributions from others) until the topic was shifted to Issues, by which point it's likely no-one would want to discuss the solution/implementation.