Request to the LW team: Clean up the list of open Github issues. In the past I’ve frequently looked at that page and declined to submit an issue because that seemed pointless with 600+ open ones. Eventually I did begin to submit issues and even got quick responses, which I found surprising given the backlog. But now that I’ve actually begun skimming the backlog (oldest first), it appears that a significant fraction of old open issues are resolved but unclosed.
In any case, a stale Github backlog makes it hard for outside contributors a) before submitting a new issue, to check whether there’s already an open issue on the topic; b) to contribute their own pull requests (as they can’t be sure that the issue is actually unresolved, rather than merely marked as open; example); c) to judge whether the state of development is healthy or not (e.g. there’s no point in submitting bug reports to a Github repository that looks unmaintained); etc.
If it’s infeasible or prohibitively expensive to identify these issues by hand, presumably either AI or outside contributors could assist in that. For example, I just skimmed a few pages of Github issues and made suggestions to close 12 of them.
Addendum: Each Github issue gets synced to a non-public Asana card (previously to Trello, but the same logic applies) via the automation service Unito. So as a comparatively efficient solution, one which hopefully wouldn’t take too much time, you could presumably set up a reverse Unito automation which closes Github issues when their corresponding Asana card is concluded. Ideally including an automatic Github comment (maybe incl. automatic tags) to explain why and how the issue was closed (e.g. resolved, not planned).
This sounds relatively straightforward to do: Unito allows setting up two-way sync workflows (rather than the current one-way sync workflow), and neither of their pages on Asana and Github imply any significant limitation to this two-way sync functionality.
They even have a full help article on this exact integration here, and its motivation matches my original request:
create tasks in Asana based on specific GitHub issues that will then be synced together in real-time, so that as you make changes in one place, you’ll see them reflected in the other.
You can use this workflow to streamline software development management; the ticketing progress; or to align comments, assignees, custom fields, and more.
EDIT: Possibly this 2-way sync with Asana already exists, and what’s needed instead is to manually or automatically update all the old stale tasks which were still synced to Trello. Unito has a help article for the Github-Trello integration here.
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.
Request to the LW team: Clean up the list of open Github issues. In the past I’ve frequently looked at that page and declined to submit an issue because that seemed pointless with 600+ open ones. Eventually I did begin to submit issues and even got quick responses, which I found surprising given the backlog. But now that I’ve actually begun skimming the backlog (oldest first), it appears that a significant fraction of old open issues are resolved but unclosed.
In any case, a stale Github backlog makes it hard for outside contributors a) before submitting a new issue, to check whether there’s already an open issue on the topic; b) to contribute their own pull requests (as they can’t be sure that the issue is actually unresolved, rather than merely marked as open; example); c) to judge whether the state of development is healthy or not (e.g. there’s no point in submitting bug reports to a Github repository that looks unmaintained); etc.
If it’s infeasible or prohibitively expensive to identify these issues by hand, presumably either AI or outside contributors could assist in that. For example, I just skimmed a few pages of Github issues and made suggestions to close 12 of them.
I’ve now also posted this request as a Github issue here.
Addendum: Each Github issue gets synced to a non-public Asana card (previously to Trello, but the same logic applies) via the automation service Unito. So as a comparatively efficient solution, one which hopefully wouldn’t take too much time, you could presumably set up a reverse Unito automation which closes Github issues when their corresponding Asana card is concluded. Ideally including an automatic Github comment (maybe incl. automatic tags) to explain why and how the issue was closed (e.g. resolved, not planned).
This sounds relatively straightforward to do: Unito allows setting up two-way sync workflows (rather than the current one-way sync workflow), and neither of their pages on Asana and Github imply any significant limitation to this two-way sync functionality.
They even have a full help article on this exact integration here, and its motivation matches my original request:
EDIT: Possibly this 2-way sync with Asana already exists, and what’s needed instead is to manually or automatically update all the old stale tasks which were still synced to Trello. Unito has a help article for the Github-Trello integration here.
(As far as I know, that integration is a zombie and no one uses the Asana)
I think the EA Forum uses it it actively. But the LW team doesn’t at all.
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.