41–44 of 44 posts
Earlier quoted context omitted.
I never knew that my default approach is called readme-driven development :)
I guess building from specifications is so rare in software, we forgot how it's called.
nano-waterfall (nWF) - README.md -Driven Development
micro-waterfall (μWF) - ARCHITECTURE.md -Driven Development
mini-waterfall (mWF) - plan→build (iterate)→ship
full waterfool (FWF) - "you went full waterfool, never go full waterfool"Earlier quoted context omitted.
I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…
> I always find Confluence to be the place where docs go to die Yeah... I'm not a big fan either. Currently in my team we just use google docs for more dynamic stuff, and have a wiki page with links to all docs. Otherwise we know that people won't bother editing
After the initial discussion is finished, the Google doc can be converted to the [Github-flavored] Markdown and stored in the [Github] repo.
It would be a good idea to create an initial GDoc based on the markdown template from the repo.
Frankly with the speed of Github innovation, they will be adding GDoc-like commenting and collaboration soon.
Not sure how it can be integrated with git branches though.
I will say, however, that getting it running took minutes; getting auth running was nearly a full day. Just HTTP Basic auth had me writing Ruby, then giving up and using a library that hasn't seen a single commit in years.