Skip to content

Conversation

@SteveBronder
Copy link
Collaborator

This proposes allowing Stan projects to add an experimental and/or unsupported folder into their projects.

Rendered docs here

@mitzimorris
Copy link
Member

mitzimorris commented Feb 11, 2021

The main alternative is to keep our current system, which is fine though a bit too conservative for some projects to be accepted.

I am strongly in favor in keeping the current system, for the following reasons:

  • Stan is OSS - folks are free to fork the repo and distribute their experiemental systems themselves.

  • this creates new problems of gatekeeping the "experimental" projects. if there's some incentive to be a part of Stan, because Stan is fairly widely known and used, then folks will want to get in on the game. we don't want to get dragged into political and marketing battles.

  • a corollory of the above is that such systems are likely to serve the needs of specific or small communities and therefore will take Stan resources away from focussing in the needs common to all Stan users. and there are a lot of these.

I'm also worried that this will allow dependencies in an experimental system to influence the design and implementations of the core Stan libraries in ways that impede progress elsewhere.

@riddell-stan
Copy link
Collaborator

riddell-stan commented Feb 12, 2021

PyStan 2 did have an experiments submodule. In retrospect, I think it was a bad idea, for the reasons that @mitzimorris offers. I'd even emphasize the first point more. Not only is it possible to fork a project in principle, it's getting easier and easier to do so in practice---thanks to platforms such as GitHub, GitLab, gitea, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants