Patrick Steinhardt <ps@xxxxxx> writes: > I was wondering whether it might make sense to also move the list of > microprojects into the Git project itself, e.g. as something like > "Documentation/Projects.txt". This would make it easier for us to update > the list of long-running projects whenever a new project is added and > makes it easier for people to discover it. I am starting to have a second thought on this. Stepping back a bit, if we were to do this, it is very likely that I'll let the patches (to add or update entries) sit on the mailing list until the discussion beats the horse to death and then apply the final version _directly_ on 'master', as such a document is really not worth spending our usual "cook in 'next' for a week to shake out problems" mode of operation that eats quite a lot of braincycles out of the maintainer and to a smaller degree, other authors that make overlapping contributions. And this thing, being a single document, is *DESIGNED* to force all authors to make overlapping contributions (and an "easy to enter" contributions at that) that will cause conflicts. But if we are to have a single document that records a list discussion consensus *after* the consensus is reached, it does not really have to be _me_ the maintainer to do the record-keeper. And pushing as much busywork as possible out of my plate would be a good thing to ensure that the project scales. Even today, we have a lot more folks who generate patches than those who can process patches by vetting, polishing, finding problems in, making sure they play well with other topics, etc. I wonder if this is better managed as either a separate tree (like the 'todo' branch that houses "What's cooking" reports among other things) with history disjoint from the main project, or even a separate Wiki? Thanks.
