Avery Pennarun <apenwarr@xxxxxxxxx> writes: > ... Obviously I would need to write a man page, but I've been > hesitant to do that in case people have suggestions that need the > whole UI to change. Perhaps that's a chicken-and-egg problem, though,... If you fear that you might get into a situation that the UI _must_ change because it does not fit people's needs or workflows, that is a sign that the UI and the workflow it was designed to support may not have been well thought out yet. At least, you do not even _know_ if it is well thought out or not. It is understandable that people would say "sounds cool, could potentially be good, but I'll wait and see if it is real" and leave. With a clear description of "Here is the workflow _I_ assume you use. If your usage fits this pattern, this tool may be for you, and here is how it works and how to use it," it becomes easier for people to say "My usage is similar but slightly different in this way. How (perhaps slightly differently from your description) would I use it?" to help improve the tool. Investing the time and effort to get the ball rolling, whether it gets included in an official tree or not in the immediate future, is a way to show that the original author _cares_ about the feature. That would further help pursuade potential users to look at it. It is an easy mistake to make to consider inclusion to my tree your goal. It can be one of the means to give exposure to wider audience, but it does not have to be your only avenue to do so. I could throw it in contrib/ but that would help merely by giving easier access to people who decide that they want to invest their own time to see if it fits their needs and if they can improve it to match their needs. You need to do your part of convincing them that it is worth looking at it first; that is not something "throwing it in contrib/" would help at all. With proliferation of free hosting services, however, I think contrib/ area for such purposes outlived its usefulness. People can now fork and gather interested and enthused users very easily and can make *me* beg to merge from them to include their new, popular, and already polished features. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html