On Tue, Jan 27, 2015 at 2:17 PM, Mikolaj Konarski < mikolaj.konarski@gmail.com> wrote:
We already have a process that works pretty well. Create a wiki page that specifies the implementation. Notifying every Haskell user is pointless if there is no specification for them to look at. I have no idea why the specification step was skipped for this change.
Because code was the shortest specification in this case? Or, alternatively, the specification was too vague, as in, the most sensible set of changes that make these 5 imports coexist without an error? Or because the best specification was a set of detailed, readable commit messages that show the road from this vague specification to the actual decisions and code changes? With lots of time in between for others to offer suggestion for subsequent commits and catch problems?
I don't mean there's no communication problem, but specifications are not always a solution. Perhaps a wiki page should list the commits, as they were created. Or perhaps they were listed somewhere?
None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.