Thanks Mans, that’s a great summary. Super helpful.
I would say that when the @SGB approved the new voting procedure we essentially gave control over questions like this to the developers. So while I agree that the SGB should continue to think about (and act on) questions like how broad of a scope the Stan project should have, this particular decision on whether to move forward with including posteriordb (or other new projects) should be made by the Stan developers.
Here are a few other thoughts specifically on the “Arguments for NOT including posteriordb” :
-
I don’t think it’s a problem for an official Stan project to include other PPLs. In fact, I would think we should want to include other PPLs, at a minimum so that we can more easily do our own comparisons between Stan’s performance and other PPL performance on the same models. We certainly don’t want to introduce anything into Stan that could break if something breaks in a totally different PPL, but that’s not the case here. So as long as posteriordb is useful to the Stan project supporting other PPLs doesn’t seem like a problem to me and may even be an advantage.
-
Regarding feature bloat, this is an issue for all of the repositories in stan-dev. We should make our decision about posteriordb based on whether we think posteriordb is a good fit and then apply the same principles of combating feature bloat that we would for all other Stan projects. I’m not saying we always succeed in preventing feature bloat, but that’s not at all unique to posteriordb so I don’t think it’s a reason to exclude it from stan-dev.
-
Regarding the use cases being too vague, that’s possible but then we could make it less vague instead of rejecting it entirely.
So after all this discussion I’m still very much in favor of including it in stan-dev. That said, @betanalpha brought up a bunch of good points and I think it’s possible to incorporate a lot of that feedback to make posteriordb even better.