I personally never check the Github issues (though I am not the person on the team who would be most likely to do so). I think the Intercom is the most reliable channel for reporting bugs, though the Open Thread is also good.
If the Github issue tracker is indeed not in use, then I find that very disappointing.
Intercom may be a more reliable channel for reporting bugs than the alternatives (though even on Intercom, I’ve still had things slip through the cracks), but it can’t replace an issue tracker. Besides, not all feedback constitutes bug reports; others require a back-and-forth, or input from multiple people, or follow-up to ask “hey, what’s the status here?”, and all of that works much better when it’s asynchronous and in public, not in a private chat interface.
And this very comment thread is a good illustration for why open thread comments also don’t work for this purpose: they might not get noticed; the threads are kind of ephemeral; feedback is mixed with non-feedback; the original poster has no way to keep track of their feedback (I had to skim through all my recent comments to find the ones that were feedback); not everyone related to an issue gets notified when someone comments on the issue; if issues are discussed in disparate threads, there’s no bi-directional crosslinking (if Github issue A links to B, then B displays the link, too); etc.
Ultimately whatever tools the LW team use to manage the website development may work well for them. But when I want to help as an outsider, I feel like the tools I’m given are not up to snuff.
It seems to me like a public issue tracker is an obvious solution to this problem, so I’m kind of incredulous that there isn’t really one. What gives?
It’s (as a descriptive fact) not a priority to support external contributions to the codebase. My guess is that it’s also correct not to prioritise that.
I understand that that’s obviously the counter-perspective, it just seems so wild to me. I’d love to see or do a dialogue on this, with anyone on the team where it would matter if they changed their mind on deprioritising this topic.
I personally never check the Github issues (though I am not the person on the team who would be most likely to do so). I think the Intercom is the most reliable channel for reporting bugs, though the Open Thread is also good.
If the Github issue tracker is indeed not in use, then I find that very disappointing.
Intercom may be a more reliable channel for reporting bugs than the alternatives (though even on Intercom, I’ve still had things slip through the cracks), but it can’t replace an issue tracker. Besides, not all feedback constitutes bug reports; others require a back-and-forth, or input from multiple people, or follow-up to ask “hey, what’s the status here?”, and all of that works much better when it’s asynchronous and in public, not in a private chat interface.
And this very comment thread is a good illustration for why open thread comments also don’t work for this purpose: they might not get noticed; the threads are kind of ephemeral; feedback is mixed with non-feedback; the original poster has no way to keep track of their feedback (I had to skim through all my recent comments to find the ones that were feedback); not everyone related to an issue gets notified when someone comments on the issue; if issues are discussed in disparate threads, there’s no bi-directional crosslinking (if Github issue A links to B, then B displays the link, too); etc.
Ultimately whatever tools the LW team use to manage the website development may work well for them. But when I want to help as an outsider, I feel like the tools I’m given are not up to snuff.
It seems to me like a public issue tracker is an obvious solution to this problem, so I’m kind of incredulous that there isn’t really one. What gives?
It’s (as a descriptive fact) not a priority to support external contributions to the codebase. My guess is that it’s also correct not to prioritise that.
I understand that that’s obviously the counter-perspective, it just seems so wild to me. I’d love to see or do a dialogue on this, with anyone on the team where it would matter if they changed their mind on deprioritising this topic.