On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote: > I think an actual issue tracker has merit to large projects. > > And I don't think simply saying "we've always done it through a ML" or "$FOO > project is bigger than us and uses a ML" is good enough. $FOO project may very > well increase efficiency, code quality, and/or participation by implementing > an issue tracker. > > A project to consider then, might be some sort of system that interfaces with > the ML (as well as a simple REST api so that issues could be submitted from > inside emacs directly), that creates some sort of org-based issue tracker, and > then ox-html exports to a static web page or pages.
My point about duplication of effort stands. Who/how/which solution? Who has to maintain it, and does that make two places to check while managing bugs/patches? Please note I'm not a complete luddite, nor have I any real influence in any decision. However I'll point out that with limited resources, the onus to sufficiently justify a major change falls on the person(s) making the recommendation. Change "just because" or "it's prettier" tend to fall on deaf ears in technical communities. I'd argue that code quality is more improved by the proper application of version control than whether bug reports are web based. This appears to already be the case. If email is unmanageable, I'd assert that perhaps the user has a poor quality mail reader that lacks threading support, and perhaps they should find a better one. Is there a problem with submitting issues via the mailing list? Has something gone unaddressed? Do you have any statistics to show that there is decreased participation because you have to use email? Is something really inefficient at the moment? Did you have patches ignored? ------------------------------------------------------------------ Russell Adams rlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3