I’m moving the discussion from a cmdstanpyt issue, which devolved into a meta-discussion on when something’s ready to be made an issue.
My understanding is that we were trying to avoid using GitHub for discussion what should be done and instead were going to insist that issues be concrete enough that someone could implement them.
The issue I was objecting was one of two bullet points:
* Something faster to parse and create than JSON (I know this would also require changes in CmdStan). This post compares a few options: https://yuhui-lin.github.io/blog/2017/08/01/serialization
I replied to the issue:
For the second bullet, it's not concrete enough to implement, so should probably be kicked to the forums for discussion before being promoted to an issue.
to which @seantalts repliedI think "not concrete enough to implement" is a fuzzy zone - it's possible someone could read up on a good 3rd data encoding scheme and just make a PR to add it, right? This isn't a case where we have to make one perfect choice - we could support a variety of formats.
This is definitely a fuzzy zone.
Rather than people reading this one-sentence feature request and coming up with a full pull request, I’d rather encourage them to propose a functional spec and get design feedback. It reduces the risk of a lot of wasted work and hurt feelings.