i have done the advi pystan thing

[Alp Kucukelbir]

hi allen + everyone else,

GOOD NEWS.

i have written the "missing piece" that, i believe, was stopping us from getting advi into pystan. (thanks ben and jiqiang for your help!)

what's next? i see that you treat the result from optimization and sampling differently. can we write some helper functions for advi too? (it would basically look like a simplified version of what we do for sampling.)

how should we proceed? i don't want to start hijacking the pystan repo at will.

cheers,
alp

[Bob Carpenter]

That is good news. Thanks for battling your way through this.

Can you follow what RStan did for the external interface?
You should consult with Allen to make sure he's OK with the
change, since he's in charge of managing pull requests for
PyStan.

- Bob

P.S. We like to call it "contributing", not "hijacking".

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Allen B. Riddell]

A PR would be great!

[Alp Kucukelbir]

pull request created. it's a work in progress; do not merge yet.

https://github.com/stan-dev/pystan/pull/221

allen: could we chat about the remaining steps at some point? thanks!

> You received this message because you are subscribed to a topic in the Google Groups "stan development mailing list" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/stan-dev/HUEpr9lK6qo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to stan-dev+u...@googlegroups.com.

[Michael Betancourt]

In general pull requests are submitted only for branches
ready to be merged — otherwise you can just share the
branch directly and avoid unnecessary continuous
integration testing.

[Allen B. Riddell]

Without PRs, how do you code review for outside developers who don't
have the ability to create branches on the repository?

The CI burden for PyStan isn't too bad. I'm happy with early PR-as-WIP
since otherwise it's hard to do/organize line comments.

[Michael Betancourt]

Diff of the branch on the fork? The problem with a pull request
that’s not ready to merge is that there’s no immediate resolution
and it just ends up sitting in the repository. Not a big issue given
the small number of PyStan pull requests, but feels like a bad
habit. I can be convinced otherwise if it’s hard to compare branches
otherwise.

[Bob Carpenter]

> On Apr 24, 2016, at 1:31 PM, Allen B. Riddell <a...@ariddell.org> wrote:
>
> Without PRs, how do you code review for outside developers who don't
> have the ability to create branches on the repository?

I don't know of any way to do this.

What did you want to accomplish with the pull request?
Why is the pull request being submitted as a work in progress?
To get feedback on design? Feedback on coding? Because there's
some test breaking you can't figure out how to fix?

Is there a way to break it down into smaller pull requests
that are ready to go? Or a way to discuss what the API is
going to be before you start working on it?

- Bob

[Allen B. Riddell]

On 04/24, Michael Betancourt wrote:
> Diff of the branch on the fork? The problem with a pull request
> that’s not ready to merge is that there’s no immediate resolution
> and it just ends up sitting in the repository. Not a big issue given
> the small number of PyStan pull requests, but feels like a bad
> habit. I can be convinced otherwise if it’s hard to compare branches
> otherwise.
>

I'm just curious about how this would work. I've seen a lot of other
communities work with PRs that are incomplete if it's on an issue that
people care about.

[Bob Carpenter]

Whatever happens, you (Allen) are in charge of the PyStan repo,
so you should use your own judgment and use GitHub however
you see fit.

My own preference is

* email for starting a discussion,

* Wiki for a design/API doc,

* a branch for the code, which you can use to get feedback
on the coding, and

* a pull request when it's ready to be merged and just
needs a final code review.

It's a very ad hoc process, but GitHub's not really set
up to do all of those things well. Lots of people manage this
process separately in other software.

I like the Wiki at the design stage because you can edit it
to be up to date and don't have to try to infer the design
goals from the code.

- Bob