Let's say you run into an problem coding against forem, that may be your own environment set up where you need help understanding the error messageβ or maybe it's a problem with the set up and the documented instructions in the first place?
When should this be a GitHub issue and when should the post go here? Or should the #help thread even be a thing here and we direct this to GitHub always?
Top comments (9)
Making github a place for actual bugs and Forem a place for inquiries might be a good distinction. For me Forem is a less intimidating place to post. I always feel like everyone judges my github contributions and my first instinct with a bug in Forem is I did something wrong.
This is my instinct as well, and generally the culture we'd want to cultivate. There is no "wrong" forem post, though if we discover that something is, in fact, an issue through discussion here, we can instruct folks to spin up GH issues.
One distinction we could potentially draw on is the existing "bug" and "feature request" labels.
I'm a bit unsure about where I prefer to see things that might be bugs. My gut feeling says GH, because even if something turns out to not be an issue after all, it's easy to close and move on. But I also understand the desire for a more "neutral" place to post first. In an ideal world, people would feel just as welcome on our GH as they do here, if that's not the case I'd like to start fixing that first.
@rcarlson If you ever feel this on the Forem repo, please let us know!
I think this is what Forem should always strive for.
For example, I've read issues in other projects where maintainers tell people to not use the issue tracker for X or Y. Maybe people do it because they don't know what's the right place.
With that experience in mind, someone might refrain from posting an issue in Forem because they'd be giving some more work for maintainers (for "silly" stuff). But also they wouldn't know what is be the right place.
Edited for clarity on who'd need confidence to post issues
As someone who contributed to our codebase you hopefully know we're a friendly bunch. The worst that could happen is that the issue gets closed with an explanation. Also it literally is our work, unlike many open-source maintainers, we get paid for it.
Ah yeah. I wasn't telling this because of me but for other people π
Sorry not making that clear
Anyone feeling unsure about posting issues on GitHub should see my issue list ππ
Bugs should continue to be posted on GitHub, via which many of the newer contributors find it easy to find them and start contributing to Forem.
A very initial/early-stage feature request discussion should start off here but later down the line should be converted to a GitHub issue once "What all things are to be done" are clear.
A "#help" thread for confusions should be a thing on this platform, and we could take benefit of the editor's capabilities to link related Issues/PRs. I also loved another post about having "wikis" on Forem.dev which if implemented would go hand-in-hand with this.
I think all bugs should be tracked on GitHub issues over forem.dev posts. The problem is it is really hard to know what is a bug and what is not. I don't think there is a wrong post for GitHub issues either. I understand why active FOSS projects try to push user support out of GitHub issues because supporting the user base can often cause a bunch of noise for contributors that are trying to fix bugs and add features.
An example would be forem.dev/avalerionv/difficulty-in... which most likely should have been a GitHub issue to start out with but it was going to be a lot of work to ask the user to open an issue instead of following up in their forem.dev #help post.
I just want to help people use Forem as quickly and easily as possible and it is easier for me to track everything GitHub because that is where the code changes/fixes will get pushed. I don't think there is a wrong spot for this kind of stuff and it is going to be a mix between the two systems.