------art_1790_10836503.1331003684921
Content-Type: multipart/alternative; 
	boundary---art_1791_29217197.1331003684921"

------art_1791_29217197.1331003684921
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This is probably one of this topics that will get little attention. 
Nonetheless...

Have other developers started to feel like the *configuration* files for 
all the various project tools they use are starting to overshadow the rest 
of the project files? For instance, In many of my projects the meat of the 
project consists of a few source directories `lib/`, `test` (or `spec`) and 
sometimes `bin/`, usually four general documentation files 
`README`, `HISTORY`, `LICENSE` and `MANIFEST` and then of a few non 
vcs-tracked things like `pkg/`, `log/` and `web/` directories. All the rest 
consist of various configuration tool files. A quick look at various 
projects on github provides:

* .git
* .gitignore
* .document
* .rdoc_options
* .yardopts
* .yardoc
* .autotest
* .travis.yml
* .rspec
* .ruby
* .test
* .braids
* .vclog
* .rvmrc
* .rbenv-version
* .test-unit.yml
* .gemtest
* .gemspec -or- foo.gemspec
* Guardfile
* Rakefile
* Gemfile
* Gemfile.lock
* Procfile
* config.ru

And there are no doubt many more. Feel free to mention notable ones I've 
missed.

Now, obviously not all of these will apply to every project. But I can 
imagine that given enough time and a rather thorough developer, a 
project could acquire configurations for a couple dozen tools. Think code 
coverage, code analysis, IDE/RAD configuration, etc. I suspect there is a 
saturation point --at some point it just becomes too much to remember. Even 
so, it could amount to quite a few files, well exceeding the number of 
toplevel "meat" files of a project.

Another thing to notice is that there are almost universally two file 
formats: Ruby or YAML, and three naming schemes: dot files, Foofile files 
and lowercase with special extension files. 

While there are obviously some files that will always remain (e.g. .git), I 
wonder if it is possible for a convention to ever develop to mitigate all 
this. Most likely that would be in the form of a common directory to hold 
all these files, although conceivably, it could be in the form of a couple 
of shared files --one for Ruby code and one for YAML.



------art_1791_29217197.1331003684921
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

This is probably one of this topics that will get little attention. Nonetheless...<div><br></div><div>Have other developers started to feel like the *configuration* files for all the various project tools they use are starting to overshadow the rest of the project files?&nbsp;For instance, In many of my projects the meat of the project consists of a few source directories `lib/`, `test` (or `spec`) and sometimes `bin/`, usually four general documentation files `README`,&nbsp;`HISTORY`, `LICENSE` and `MANIFEST` and then of a few non vcs-tracked things like `pkg/`, `log/` and `web/` directories.ll the rest consist of various configuration tool files. A quick look at various projects on github provides:</div><div><br></div><div>* .git</div><div>* .gitignore</div><div>* .document<br></div><div>* .rdoc_options</div><div>* .yardopts</div><div>* .yardoc</div><div>* .autotest</div><div>* .travis.yml</div><div>* .rspec</div><div>* .ruby</div><div>* .test</div><div>* .braids</div><div>* .vclog</div><div>* .rvmrc</div><div>* .rbenv-version</div><div>* .test-unit.yml</div><div>* .gemtest</div><div>* .gemspec -or-&nbsp;foo.gemspec<br></div><div>* Guardfile<br></div><div>* Rakefile</div><div>*emfile</div><div>* Gemfile.lock</div><div>* Procfile</div><div>* config.ru</div><div><br></div><div>And there are no doubt many more. Feel free to mention notable ones I've missed.</div><div><br></div><div>Now, obviously not all of these will apply to every project. But I can imagine that given enough time and a rather&nbsp;thorough developer, a project&nbsp;could acquire configurations for a couple dozen tools. Think code coverage, code analysis, IDE/RAD configuration, etc. I suspect there is a saturation point --at some point it just becomes too much to remember. Even so, it could amount to quite a few files, well exceeding the number of toplevel "meat" files of a project.</div><div><br></div><div>Another thing to notice is that there are almost universally two file formats:&nbsp;Ruby or YAML,&nbsp;and three naming schemes: dot files, Foofile files and lowercase with special extension files.&nbsp;</div><div><br></div><div>While there are obviously some files that will always remain (e.g. .git), I wonder if it is possible for a convention to ever develop to mitigate all this. Most likely that would be in the form of a common directory to hold all these files, although conceivably, it could be in the form of a couple of shared files --one for Ruby code and one for YAML.</div><div><br></div><div><br></div>
------art_1791_29217197.1331003684921--

------art_1790_10836503.1331003684921--