> This idea that the tools used by a potential contributor are inadequate > misses the point. If the intention is to keep a project going, or better > yet increase the number of contributors, tools have to be used that will > be convenient and familiar to those thinking about contributing. > > For better or worse, the workflows embodied by Github and Gitlab are > familiar to the current generation of potential contributors upon which > sustaining a project will depend. > > Holding up the 'Linux uses email for development and thus any project > doing similar is right' fails to recognize the peculiar nature of the > Linux kernel (and its developers) and neglects the thousands of projects > that have increased their visibility and participation by using tools > such as Github. I agree that Github/Gitlab may not be the best choice > owing to their stance or implementation related to software freedom, but > an honest discussion of alternatives seems prudent.
This is the point I am trying to (un-eloquently) make. I'm seeing a bunch of younger coders interested in emacs (mostly spacemacs and doom); but, they get frustrated with the ancient (to them) dev practices. I'm not advocating any rash decisions; simply, whether the project would benefit from incorporating some sort of simple issue tracker, so that new contributors could readily see open tasks / issues / submit bug reports. My biggest issue with a ML only approach is that it's not easy to see what's an open issue unless you spend a long time searching and reading the ML. And I feel that that time could be better spent learning the code base instead of reading the ML. -- James Miller james.ryland.mil...@gmail.com
