I agree that several things are made a bit more challenging by not using something 'a la github' (note: I am used to github quite well, so maybe some of the points I mention here are also doable with the current solution, but more challenging to find how to do it, at least to me):
- it is a bit more challenging to search through threads in the mailing list than through issues IMO. Also, issues can reference to each other, get closed, assigned tag / responsibles, etc. - it is a bit more challenging to keep track of the patches etc that are being proposed, compared with pull requests / feature branches. More difficult probably for people to build on each other's patch, rather than contributing on forked repos. - it is a bit more challenging to 'intermix' code and discussions in mails than in for example github, i.e., no permalinks for discussion, etc. - it may be higher barrier for casual users to report glitches / challenges, etc. Though this may be as much a blessing as a curse of course. In the end, everything is a tradeoff, so the question maybe should be: what are the pros and cons of each approach? We know github is not perfect, but what would be actually lost using it? As pointed, people still will have local copies, it will always be possible to leave if their policy changes, or other. Another question is, what do you want as user group for this package / as casual devs level? Do you want to have an 'elitist' package or something that more people may get involved in? I guess this is also a tradeoff. On Thu, May 21, 2020 at 1:30 PM Nicolai Dagestad <nico...@dagestad.fr> wrote: > > > However, this comment got to the core of one of the challenges. Not > > having a bug tracker, PR list, issue tracker, whatever leads to patches > > languishing on the list and being either re-bumped or lost. Right now > > the pace of the project is not allowing code to get committed. I don't > > need another active project to track, but knowing that a periodic > > check-in by the maintainers would be easy enough for them to cruise > > through a list of pending work, might allow that happen more frequently. > > Maybe something like sourcehut (https://sourcehut.org) could help with the > workflow.