emacs-devel, on maintainership
The recent "emacs dumper" thread on emacs-devel, while tumultuous, also contains some of the best readings on maintainership I've ever read.
- A post by Matt Armstrong, about understanding difficult maintainership positions, as a contributor.
- A post by John Wiegley, current co-maintainer, to the other co-maintainer Eli
- @Karl Fogel sharing experiences on maintaining SVN.
Claes Wallin (韋嘉誠), Yutaka Niibe, joeyh, Jason Self and 3 others likes this.
Claes Wallin (韋嘉誠), Sarah Elkins, Karl Fogel shared this.
From Armstrong's post:
I do agree that submitting patches to projects on "non github" systems is beginning to feel archaic.What. No! An emacs developer already spending significant effort on changing obscure internals would be able to handle registering an account and doing git push. I understand the inessential weirdness and inclusiveness aspects of using command-line tools rather than web tools, but this is not a newcomer who is facing a cultural threshold. And I really don't think Free Software projects have any business being on github if they can help it. Maybe being on a "non-web" git repo would be obscure, I like that I can send http references to people taking them directly to some file, diff or tree, and if a thing isn't on the web it is less of a thing. But the pull request and commenting functionality on github is not essential to a project with a pre-existing high technical literacy threshold.
The point that Savannah could benefit from a face-lift stands. I just have a very strong gut reaction to someone saying that hackers using git in the most essential git way is something archaic. Git is less than half the age of the web. Who's "archaic"?
I don't know why, but it seems to be my method to
immediately get worked up by the nit picks. I should focus more on the meat.
Overall, the three messages you linked show a very insightful and enlightening discussion. I can definitely identify with Armstrong's perspective. In my day job, we have very limited staff for all the things we would like to do, and every time a developer (whom we serve -- I work on the build system) has a brilliant idea for "just a quick fix that will improve everything for everyone", it's really frustrating because we know they will have zero time to maintain it, so it will end up on our already rather cluttered desk and be a drag on our own velocity, and so delay more fundamental changes that would really make a difference for everyone. Working on the build system is great, every time we make a small improvement, dozens of people become more productive. But that leverage also necessarily makes us conservative. I can't imagine what it's like to work on a tool used for making dozens of thousands of people more productive.
Wiegley and Fogel's perspective seems to be very much in the spirit of Hintjens's C4, or C4.1 (latest spec at 42/C4*), which in his community had extraordinary dynamic effects on the community, so great that they, according to his assessment, greatly compensated for any maintenance burden incurred by being more accepting of changes to the code.
Commercial development has limited resources (although community management matters to internal projects as well!). Community development has whatever resources it can avail itself of. It can create more resources just by maintaining an inviting project atmosphere.
I absolutely see where Armstrong is coming from, but I hope he listens to the others.
* Is this what's called "C4.1"? I don't see it mentioned in the spec itself, it just calls itself C4 there.
Overall, the three messages you linked show a very insightful and enlightening discussion. I can definitely identify with Armstrong's perspective. In my day job, we have very limited staff for all the things we would like to do, and every time a developer (whom we serve -- I work on the build system) has a brilliant idea for "just a quick fix that will improve everything for everyone", it's really frustrating because we know they will have zero time to maintain it, so it will end up on our already rather cluttered desk and be a drag on our own velocity, and so delay more fundamental changes that would really make a difference for everyone. Working on the build system is great, every time we make a small improvement, dozens of people become more productive. But that leverage also necessarily makes us conservative. I can't imagine what it's like to work on a tool used for making dozens of thousands of people more productive.
Wiegley and Fogel's perspective seems to be very much in the spirit of Hintjens's C4, or C4.1 (latest spec at 42/C4*), which in his community had extraordinary dynamic effects on the community, so great that they, according to his assessment, greatly compensated for any maintenance burden incurred by being more accepting of changes to the code.
Commercial development has limited resources (although community management matters to internal projects as well!). Community development has whatever resources it can avail itself of. It can create more resources just by maintaining an inviting project atmosphere.
I absolutely see where Armstrong is coming from, but I hope he listens to the others.
* Is this what's called "C4.1"? I don't see it mentioned in the spec itself, it just calls itself C4 there.
Claes Wallin (韋嘉誠) at 2016-12-17T13:11:45Z
Christine Lemmer-Webber likes this.
According to 16/C4, 22/C4 would be "C4.1". Apparently he later gave up on that versioning scheme, as 22/C4 and 42/C4 are also just "C4".
Glad we got that sorted out. Now I can do whatever I was supposed to be doing. Ah yes, watching that movie about that fish that forgets what she's doing. It's a better movie than I expected, I think.
Glad we got that sorted out. Now I can do whatever I was supposed to be doing. Ah yes, watching that movie about that fish that forgets what she's doing. It's a better movie than I expected, I think.