Should items like this be github issues?
Is there a repository for chat.blockstack.org? If so, the person(s) is responsible for it, can create a corresponding issue (I’d look at it like a “work item”) to remind developers it needs to be fixed.
My view is that we can’t expect everyone to know which software package is causing something to be broken. This will only get worse as people less familiar with the architecture of Blockstack start reporting problems.
Incoming problems can be reported here and then the responsible person(s) can triage them and open github issues on the relevant repositories.
What do you think?
We are using https://github.com/blockstack/blockstack/issues for all the smaller stuff.
I feel when it comes to actual issues we use GitHub and the Forum should be used as a reference guide or FAQ. But either way would work. I’m just afraid that if we do not have a lot of activity on GitHub, we won’t get as many people contributing.
Github issues can also be linked from here as needed. As larry did in a post earlier.
I do see the point about reducing redundancy and we should figure out a guideline about what should be reported as a Github issue.
I’m not too worried about Github activity. Our codebase is fairly active and a new developer would get the impression that it’s an active project.
Here’s a protocol we can use:
- A user can start a forum topic here
- We engage and triage the situation
i. If the problem is unique and hasn’t yet been reported, we ask the user to submit a GitHub issue
ii. If the question has been asked before and falls under technical support, we respond and help here
iii. If the problem pertains to onename.com, we ask them to send an email to [email protected]
2 Likes
Would be really cool to have such guidelines available on GitHub, so that others can apply them by themselves or even contribute to them. And if they got written down once, there’s a much smaller chance of misconceptions 
Sounds like the technique you use for putting questions from Slack into this forum. Only difference is, that you start the posts here on behalf of a user. I guess it’s to lower the barrier to get in contact and thus get the forum running.
Would that be helpful with GitHub issues too?
1 Like
Came across Atom’s policy on github/forum: http://blog.atom.io/2016/04/19/managing-the-deluge-of-atom-issues.html
A lot of items that come in on Issues are not bugs or feature requests, they’re questions or discussions. A lot of these questions can be answered by anyone in the community; they’re not exclusive to an Atom maintainer. For feedback like this we set up Discuss [forum], the official Atom and Electron message board. It’s a great place where people can get all kinds of help, whether it is about using Atom or creating themes or packages.
The general rule of thumb is that GitHub Issues is best for things that have a definition of “done”: they can be fixed, added, resolved, have a stake driven through its heart or otherwise laid to rest. For things where there isn’t a clear goal or end state, where you want to debate theory, or ask questions Discuss [forum] and the Atom Slack are the way to go.
So we’ll be encouraging people to use the best channel for their feedback more. If you ask a question on Issues and get a simple answer and reminder to check Discuss, it’s because we want you to get the help you need as quickly as possible.
There’s also a tool that can be used to move GitHub issues (such as ones that are mostly discussion) over to a discourse instance. Would be interesting to try it out on some of our historical discussion issues such as these: https://github.com/blockstack/blockstack/issues
2 Likes