Hangouts Link: https://meet.google.com/gzm-wmum-pfm
Instructions: Ask to attend in the hangouts interface and someone should let you in in the first 10 minutes of the meeting. Email breck@mc-stan.org if you have problems or want to attend the physical meeting in New York City.
Please add your agenda items in replies.
Electorate Discussion: Stan Electorate for Referendums and Elections
fit[i] or fit$iteration[i] and related discussionI’ll be late for the meeting, so you can skip these as it seems there is a lot to talk anyway,
@ducoveen and I are wondering whether we should go ahead with StanCon Utrecht or whether we should drop the idea and start spending our time on something else. We have a website and a venue on hold. Now is the moment to approach sponsors if we want to go ahead with it. We hope that the Stan meeting could shed some light on the community’s preference on what to do here.
@betanalpha has a proposed change to timestep adaptation. I want to introduce that to the interface folks and solicit opinions (tldr; it results in a larger timestep: Request for Volunteers to Test Adaptation Tweak but has more divergences: Request for Volunteers to Test Adaptation Tweak).
I won’t be at the meeting but your website looks great! Does the SGB decide where the next conference is held?
Stan-wide Report for what happened last week
Not sure if I can make it but just in case I’ll add my agenda item - does Stan need a roadmap?
I noticed on the discussion that there’s a lot of discussion about the roadmap for tech stuff on Stan. I wonder if this is such a particularly massive job because the roadmap/priorities should be coming from Stan as an organization rather than the TWG of Stan. Obviously the TWG needs a roadmap, but I wondered if maybe having a set of priorities for Stan might lighten the burden (i.e., Stan prioritizing interfaces, Stan prioritizing algorithm modularity,…). I’m not super sure on this, but thought it might be worth raising for discussion.
this is a lot of things to discuss at an online meeting. most of these topics would be better discussed via the Forums, as this provides an open records of the discussion and allows everyone to participate asynchronously - I suggest we not discuss:
I won’t be able to make the meeting - I will be attending a meetup for the Paris WiMLDS - Bob’s planning to come with as well (looks like a great set of topics - https://www.meetup.com/Paris-Women-in-Machine-Learning-Data-Science/events/264779976/?rv=ea1_v2&_xtd=gatlbWFpbF9jbGlja9oAJGVkYzEwNWFjLWMwZTgtNGI0Mi1hYTk0LTMyYzdkMzRhNTI5Yg)
here is my report for the week:
Yesterday I gave a talk on “Bayesian Workflow and the Stan Ecosystem” to a group of reseachers at INSERM, which is the French equivalent of the in-house research branch of the NIH. I was invited by Lucie Biard, who worked with France Mentre - her group uses Bayesian methods for adaptive clinical trials, meta-analyses, and cohort data in rare diseases. Only 3 people in the room (audience of about 25 people) use Stan, one researcher uses RJAGS, almost all of them have used lme. Given this, I talked mostly about BRMS and bayesplot. The report back from Lucie is that people enjoyed the talk and several of them said that they will give BRMS a try.
see y’all in NYC next week!
I think we need meetings and online discussions. Both methods have advantages and disadvantages and developing a habit of using both helps with transparency, communication and decision making.
For decisions I am trying to
The “Stan wide report” is an effort to put in one place a record of what decisions have been made, are being made or are being discussed. It will exist in both written and verbal form. I am seeing serious communication issues because people don’t know that decisions are being made.
Definitely. In the role description for the TWG Director, it was said that the SGB would write out and hand off goals and priorities to the TWG Director, who would work to implement them. I waited a while for that but it became clear the SGB would not be able to create such a document. I still think we need such a thing though - not sure how to create it with our group. If there are 5 people there are 10 conflicting goals, haha. Definitely welcome advice for how to think about this and generate some goals or mission statement we could all mostly get behind.
Agreed, I expect we’ll have to cut it off and pick up next week at some point.
I agree with both of you here - meetings and forums each have a purpose. In general I think there are probably some topics where it makes sense to try to find some time in the next ~month where the maximal number of interested stakeholders can meet. Things just move so much faster in a meeting and people don’t get nearly as pissy with each other. That said, I think we should wait until next week for the electorate discussion so Bob and Mitzi can attend.
We can see who is actually at the meeting - there were probably 5 voices going back and forth on the fit[i] thing on the forums. If some from each camp are at the meeting we may be able to make some progress in what each individual believes to be best and report back on the thread.
Yes @mitzimorris my apologies! I didn’t intend to be exclusive! I’m just not sure how to make a suggestion to the SGB, which is I guess who I should have suggested this too…? I also am not sure this is the best approach, so I wanted to give my suggestion the option to be shouted down quickly. :) 100% agree that maybe the Columbia meeting isn’t the best place to raise this.
@breckbaldwin can I suggest this to the SGB? Would it be better to wait until after the election? Sounds like you’ll have your hands full before then. :)
what is a verbal record? and how can having two different records make anything clearer?
this is a big departure from what was advertised last summer - cf.
here’s what was cited as the source for how to structure the project:
https://producingoss.com: “Producing Open Source Software: How to Run a Successful Free Software Project”
chapter 2: “Setting the Tone” (Setting the Tone)
Avoid Private Discussions
Even after you’ve taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. This is especially true in the early days of the project, when there are so many important decisions to make, and, usually, few people qualified to make them. All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in email conversations, the need to leave sufficient time for consensus to form, the hassle of dealing with naive newcomers who think they understand all the issues but actually don’t (every project has these; sometimes they’re next year’s star contributors, sometimes they stay naive forever), the person who can’t understand why you only want to solve problem X when it’s obviously a subset of larger problem Y, and so on. The temptation to make decisions behind closed doors and present them as faits accomplis , or at least as the firm recommendations of a united and influential voting block, will be great indeed.
Don’t do it.
As slow and cumbersome as public discussion can be, it’s almost always preferable in the long run. Making important decisions in private is like spraying contributor repellant on your project. No serious contributor would stick around for long in an environment where a secret council makes all the big decisions. Furthermore, public discussion has beneficial side effects that will last beyond whatever ephemeral technical question was at issue:
- The discussion will help train and educate new developers. You never know how many eyes are watching the conversation; even if most people don’t participate, many may be lurking silently, gleaning information about the software.
- The discussion will train you in the art of explaining technical issues to people who are not as familiar with the software as you are. This is a skill that requires practice, and you can’t get that practice by talking to people who already know what you know.
- The discussion and its conclusions will be available in public archives forever after, enabling future discussions to avoid retracing the same steps. See the section called “Conspicuous Use of Archives”.
Finally, there is the possibility that someone on the list may make a real contribution to the conversation, by coming up with an idea you never anticipated. It’s hard to say how likely this is; it just depends on the complexity of the code and degree of specialization required. But if anecdotal evidence may be permitted, I would hazard that this is more likely than you might intuitively expect. In the Subversion project, we (the founders) believed we faced a deep and complex set of problems, which we had been thinking about hard for several months, and we frankly doubted that anyone on the newly created mailing list was likely to make a real contribution to the discussion. So we took the lazy route and started batting some technical ideas back and forth in private emails, until an observer of the project[22] caught wind of what was happening and asked for the discussion to be moved to the public list. Rolling our eyes a bit, we did — and were stunned by the number of insightful comments and suggestions that quickly resulted. In many cases people offered ideas that had never even occurred to us. It turned out there were some very smart people on that list; they’d just been waiting for the right bait. It’s true that the ensuing discussions took longer than they would have if we had kept the conversation private, but they were so much more productive that it was well worth the extra time.
Without descending into hand-waving generalizations like “the group is always smarter than the individual” (we’ve all met enough groups to know better), it must be acknowledged that there are certain activities at which groups excel. Massive peer review is one of them; generating large numbers of ideas quickly is another. The quality of the ideas depends on the quality of the thinking that went into them, of course, but you won’t know what kinds of thinkers are out there until you stimulate them with a challenging problem.
Naturally, there are some discussions that must be had privately; throughout this book we’ll see examples of those. But the guiding principle should always be: If there’s no reason for it to be private, it should be public.
Making this happen requires action. It’s not enough merely to ensure that all your own posts go to the public list. You also have to nudge other people’s unnecessarily private conversations to the list too. If someone tries to start a private discussion with you and there’s no reason for it to be private, then it is incumbent on you to open the appropriate meta-discussion immediately. Don’t even comment on the original topic until you’ve either successfully steered the conversation to a public place, or ascertained that privacy really was needed. If you do this consistently, people will catch on pretty quickly and start to use the public forums by default.
Hi, Mitzi. I agree that public discussion is the way to go. We need multiple channels. Discourse is great but the threads can quickly disappear. We’ve also been talking about adding a “newsletter” channel for important items that can reach everyone in the community without these items getting forgotten. Perhaps each newsletter item can link to a Discourse page so there will be a way to discuss. In addition I like the idea of each Stan meeting having a scheduled agenda and a discourse page so that people who can’t make it to the Stan meeting can participate in other ways.
P.S. I hope your workshop went well. Say hi to Paris for me!
Brief notes:
Matthijs: Some StanC3.
Ben: Uploaded RStanArm, got rejected.
Steve: Met with Dan S, working on Sparse matrix, adding to design doc.
Andrew: Golf case study up, permission to have BDA free online
Charles: Working with Yi to get Newton solver into Stan. Working on monster model.
Rok: Buch of openCL stuff. Working on learning compiler.
Ben B: MRP stuff, had idea that didn’t work out.
Jonah: RStanArm release, RStanTools 2.0 out.
Sean:
General Meeting:
Please announce online, too. I think that was the intent given the second item, but just in case…
I don’t see any problem with discussing things in meetings as we can hardly require a general assembly for every discussion. I just don’t want binding decisions to be made “in committee” without consulting the wider project. And it’d be helpful to summarize in-person meetings for everyone else if only to save time and rehashing.
Breck told me to send email to board@mc-stan.org. I tried once and @syclik responded.