Cleanup issues github/ipfs/go-ipfs

I’m currently looking into making the issue template in github/ipfs/go-ipfs nicer and noticed that
a lot of “issues” are actually more kind of a discussion without beeing really “actionable”.

This results in a lot of stale tickets floating around (it’s now nearly 1000 tickets!).

I think it makes sense to leverage the new feature of “discussions” here for feature discussions,
without pointing developers and users to switch between platforms (like to discuss.ipfs.io).

With issue templates we could move people seamlessly to the discussion platform and present a
nice looking selection page, which let them choose which kind of feature or topic they like to
propose/discuss.

This would allow us to clean up the issues, to boil them down to “just” issues, which need to be
addressed - like limitations, performance issues and actual bugs - and move everything not related to a single actionable thing, like meta issues, discussions about potential features and maybe even release checklists to thd Github discussion page.

I think that would make the issue tracker much more clearly for the programming team, while the
discussion section can be used for feature discussions, without having to move them to other repos,
like github/ipfs/notes/issues where they seem to just stale and get duplicated from time to time in
the go-ipfs repo.

We could also use the github/ipfs/notes repo for general discussions with the discussion function of
the protocol, which are currently in github/ipfs/go-ipfs/issues, github/ipfs/notes/issues, github/ipfs/roadmap/issues, and sometimes now in
the forum
.

This would also allow us to remove the split between the two platforms. I think all development
stuff should stay on github, while the forum is more for technical support as well as open
technical discussions without a development purpose.

TL;DR:

  • Issues should be actionable
  • Discussions about features/bugs/limitations should be in github/ipfs/go-ipfs/discussions
  • General community discussions, questions, technical help etc should be posted here (discuss.ipfs.io).

Let me know what you think! :slight_smile:

//cc @stebalien @lidel @jessicaschilling

+1 to issues being actionable.

lotus uses GitHub discussions and it seems to work well there. Unfortunately, discussions are per-repo; that’s why I’ve been pushing as many discussions as possible here so we have a central place for them. I’d rather not have to participate in discussions across js-ipfs, go-ipfs, go-libp2p, js-libp2p, etc, etc.

We could have discussions in ipfs/ipfs, I guess… Alternatively, we could direct amorphous go-ipfs/js-ipfs feature requests into GitHub discussions while leaving general-purpose discussions here. However, I’m concerned about fracturing the community.

We made a very clear choice last year to have all help requests and semi-technical discussions in the forums, and keep the repositories for repository-specific, technical discussions.

This included closing or heavily discouraging the use of ipfs/ipfs, ipfs/notes etc. which were just fragmenting discussions that are now expected to happen here in Discourse.

This was before Github discussions existed so they were not considered, but I also not feel bad about not putting even more things inside the walled-garden that Github is. The registration/login workflow here with Github credentials is very straightforward anyways. I would also add that Github search sucks very bad and that Discourse is way better for discoverability.

Finally, go-ipfs issue tracker has many open issues, but it has also been a choice to keep everything that might be remotely actionable, ideas and discussions open there (again, there were no Github discussions). I think it has been a choice to not do more aggressive cleanup in this tracker (which I was in favor of), because in the end it added little value and could cause the feeling that we are dismissing good ideas or legit worries, even if they were not actionable.

I hope the explanations above provide some perspective on why things are like they are (the official “policy” of what goes where is Getting Help). I am personally not in favor of making changes as things are not broken enough from my perspective, and changing discussion venues or having more rules have risks (like devaluating the forums where so much information lives already).