[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 1. Maintainers often say "no" to certain things (like code refactoring > that does not lead to any clear improvement) because they know from > their extensive experience that some ideas are "non-starters". > However, they do not elaborate much why one or another thing is not > acceptable. > Not elaborating is actually perfectly understandable - it would be > annoying to repeat the same thing many times and would also waste the > maintainer's valuable time that could be spent for something more > productive. I think I can understand why this feels painful -- but what concretely could we ask the maintainers to do which would be better overall? When you say "maintainers", do you mean the Emacs maintainers (currently Eli, Stefan and I)? Or does it mean the people who develop whichever file you're proposing a change to? > 3. Sometimes, replies to certain feature request feel like a show > stopper not because the feature itself is not acceptable, but because > the specific implementation is not deemed good. Would it be halp if the people who respond make an effort to distinguish between their comment about the the behavior tat could be changed, and their comments about the specific method of implementing that change? We might be able to get better at that, since I expect everyone will agree it is good to do that if one can. I'll reply to #2 privately. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
