Monthly Math library planning meeting

maintenance
math

#1

Hi all,

I’d like to set up a monthly planning meeting just for the Math library. I would like to default to a 30 minute meeting. We can always add additional meetings if necessary. If anyone would like to join me, please let me know.

At these meetings, I’d like to:

  • take a snapshot of the state of the Math library; open issues, open pull requests, any hurdles, etc.
  • assign tasks; this may be things like reviewing pull requests, figuring out who needs help in development, etc.
  • try to find actionable ways to improve the math library

Once I have a sense of who wants to meet, we can try to schedule something with those interested.


#2

I’m interested.


#3

I’m in.


#4

Sweet! It won’t be a one-person meeting.


#5

I’d like to join.


#6

Great! I’ll give it a few more days (until the Stan meeting) and then we can start scheduling a time.


#7

I would meet


#8

Thanks all. Moving the logistics of arranging the meeting to private. Will announce the time that’s been decided for anyone else that can make it.


#9

I’m interested in attending. How do you see this meeting in relation to the weekly Stan meeting?

GitHub provides the snapshot. We just need to decide how to act on it. :-)


#10

I would also like to come!


#11

We have a meeting set up for next Wednesday. Will post minutes after the meeting.


#12

Next week won’t work for me, but if you could forward the invite, that would be great.


#13

I’m in!


#14

+1


#15

I’m interested


#16

We just had our first meeting online. Thanks to all that participated: @syclik, @bbbales2, @sakrejda, @roualdes, @drezap, @Bob_Carpenter, @seantalts, @Stevo15025, @yizhang, @increasechief.

There was a log of good feedback. Here’s what we decided to do:

  1. Over the next month, put together a standard for reviewing pull requests. This discourse thread is a starting point: Standard for reviewing pull requests in the Math library
    • This will include:
      • how to review a pull request correctly
      • who should review a pull request
      • @seantalts, mind filling in whatever questions you have that I didn’t write down?
    • This will go on the Math wiki.
    • We should encourage more people to review code. We can do this by splitting apart reviewer tasks across different people since a lot of pull requests are multi-faceted.
  2. We discussed the next release of Math and Stan. We will release Math v2.18.0 and Stan v2.18.0 when CmdStan has MPI ready to go.
  3. For the 1-d integrator pull request, we need to go through and see if a decision has been made regarding Boost. If it hasn’t, we need to clearly come up with a decision. If it has, we need that to be clear.

We currently have:

  • 149 open issues
  • 12 open pull requests
    • only 7 pass tests

Some other things we need to do:

  • prioritize what we should work on for the Math library
  • we need criteria for making decisions
  • clarify decisions when they’re made

We can pick those up following the next meeting.


#17

I thought we decided to go with the Boost version and we were going to let Marco know and Ben Bales was going to take over the issue.

If that’s not the decision, can you indicate what needs to be done to enable a decision?

Until new governance lands, the final decisions of what to do and how to do them are up to you. Obviously, you want to use a light touch here and let the developers make most of the dev-oriented decisions. What we need are clear decisions about what to do. So these two are important:


#18

I looked through the issue again. There wasn’t enough information.

Yes, here’s what I wrote on the pull request as a comment

Here’s the summary of the discussion:

  • @bgoodri believes we can go with Boost for the implementation
  • @bbbales2 has volunteered to implement this summer using Boost
    Can someone verify that the Boost implementation is good enough for us to use and replace our current implementation?

That’s all I need to enable the decision. That Boost is good enough to use and replace our current implementation. I’d just really like an explicit “yes” from someone that’s looked into it. Reading the thread without knowing the implementation, it looked like a “definite maybe” – sounded like it was more advanced in ways, but behind in others. I don’t know if it’s behind in critical ways.

So… @bgoodri, do you think that the Boost 1-d integrator covers our current use case for the 1-d integrator?


#19

This makes it sound less like we need a decision and more like we need: 1) some tests of what the two integrators can handle; and 2) figure out what types we need the integrator to handle.


#20

Yes, and it goes beyond what we were envisioning before.