How to use discussions vs issues

[wolftune]

I have some tension with the duplication of issues and discussions here. Issues themselves have discussion functionality. I don't think it makes sense to make issues and discussions both for each topic. If a topic is unsure, not ready to be an issue to resolve, such as what packaging system(s) to use, that seems appropriate to a discussion maybe and then make an issue for the actions that come out of the discussion. Starting both at once doesn't feel right.

[wolftune]

In the case of #7
I think it would be fine to have the issue right away given being confident that we want to do it, and in that case, the discussion is maybe appropriate too, but the discussion topic would be something like "packaging options?" and instead of duplicating the opening content from the issue, it would say something like "I already opened one for FlatPak because I think we should do that. Any concerns? Any other packaging we should be considering at this time?"

[starofrainnight]

Yes, you are right, I starts that discussion and just think it's seem an issue (task or related) not a normal discussion.
So then I convert it to an issue :)
I agree all your ideas about discussions vs issues, I had never think about their difference so clear like you describe. Learned, thank you 😆
I think you are more experienced than me in this field (how to maintain a community & organization), so just edit them, move them or do whatever if you think is not the right way or told me what should I do, you have my full support 😄

[wolftune]

Sounds good, feel free to open whatever. Trying things, taking action, and then iterating, that's a healthy process. We need not get perfect ideas about discussions vs issues strictly. Thank you also for being open to feedback and editing. This makes a good dynamic workflow.

I now see that discussions are across the org while issues are per-repository.

I think a guideline to consider (not strictly) is that issues should be closeable via commits. That is still a rough guideline because even a discussion can lead to deciding to update a contributor's document or change a git-based set of documentation files or something. For that matter, we could have a separate Task Coach documentation repo someday, like Task Coach manual or something.

For now, let's say issues when we think about work-to-do, as you said. And discussions if we aren't sure whether to do something or what to do or are otherwise thinking about broad ideas or use of Task Coach etc. But we can figure out what feels best as we go

[starofrainnight]

Thanks for your encouragement! I will try my best:)

Yep, the discussions can only bind to one main project, and across the whole org but the issues only related to their repository.

Ok, no matter how rough the guideline are, have one is better than none:) Let's just take action first.