I’m the main offender here, but I’m a little older than that.
Nor has the existence of a TWG director. Before, the problem was two different opinions among subsets of developers and nobody empowered to make a decision. The bottleneck now is satisfying the tech leads that PRs are safe. Ultimate responsibility lies with the TWG director, as I believe they have the authority to override the module leads.
This is why I think this process is wrong compared to one based on voting, where this would’ve probably already been decided in favor of inclusion.
I believe the right approach is to be friendly and welcoming to everyone, while firmly insisting on our evaluation criteria. I don’t mind the top-level message of the algorithms procedure, just the get-off-my-lawn tone. I’m not sure how to handle the case where someone wants a lot of feedback during meetings, but that’s a separate issue to be handled by whoever is moderating (not ever very clear).
I don’t want to be singled out. I want everyone (who wants to be) to be included in the process on big issues. I’m OK with having authority for decisions rest in the SGB or TWG, but as I’ve said, I think voting will work more efficiently with fewer hard feelings all around.
This is a tricky issue balancing the need to be relatively conservative in our low-level modules. Adding threading (which is the currently blocked issue) is a huge change, so I think it makes sense to take it slowly.
Yet I think the tech leads if they’re going to function as such need to have the power to block PRs they think are unsafe. The problem I see is that nobody really respects their authority, which I think is endemic to a project of open-source volunteers.
The tech leads for math and algorithms are outside of Columbia, so I don’t think that’s the issue.
I think that’s spot on.
I very much disagree about this as it’s only ever a very small set of stakeholders at the meeting. I don’t think the current math lead or algorithms lead have been at a Thursday meeting in years. Do you want to insist they come to regular meetings or give up their roles?
That’s “we”—you’re part of the group.
Why have them in our repo if they’re not official Stan projects? Where do we draw the line? Can anyone who’s a stan dev start dropping pet projects into the Stan repo and branding them as “Stan”?
It’s not that I don’t like any of these projects. It’s that I want to see a consistent system enforced. As I said for these projects, I’d like to see them brought into the Stan fold rather than kicked out.
I don’t know what you mean by “plugin architecture”, but I don’t know how we can make it any simpler than exposing log densities and gradients in C++, R, and Python. All of our evaluation tools and posterior analysis tools are open.
One big exception here is students, who are typically poor by most measures other than future potential, but often have the energy, free time, and motivation to volunteer. The volunteering can be synergistic with their other work. That’s also true for a lot of academics, who I wouldn’t classify as either rich or poor.
Breck and I get a distorted view of income from hanging out with highly skilled NYC and Silicon Valley tech programmers and managers. Even in the countries with rich middle classes like the U.S., the median family income is US$60K, which is very conservatively less than half the compensation of a junior C++ programmer at Google in NYC. In many countries, US$10K would represent a large fraction of a middle-class programmer or academic’s salary.
Another problem we face is that we need a high level of competence from Stan contributors in most cases. The kind of competence with which, barring extenuating circumstances, would land a relatively high-paying job.
One opportunity for increasing diversity would be to give something like scholarships to train people in the relevant stats and programming skills so they can start contributing to Stan. That would be super expensive compared to the likely yield for the project, but it might be worth trying. I’d be game to volunteer for something like an intensive summer school (not a boot camp—if it’s called that, I’m out).
Right—I didn’t want to be on the SGB and I opted out of the TWG for reasons I tried to articulate above.
Thanks for the links. They’ll take a while to digest. But why not make that list public along with a summary rather than internal?
I’m still having trouble reconciling these two statements. My understanding is that you considered the meeting you had of a few tech leads a quorum from which to reach rough consensus. As such, you didn’t want further feedback on things you considered already decided.
If that’s not the case, then yes, I misunderstood all the stuff you sent me, told me, and posted in now delisted dev-only Discourse posts.
Isn’t that the difficult and unpopular part of the current TWG director position? What’s left for the TWG director to do?
I’m happy to help do that without having a title or extra pay.
I absolutely do not want to be the one making final decisions on things. As I said above, I don’t think I have the proper mindset to do it and I feel I have too many conflicts of interest.
I’d just like the opportunity to make my position known without having to attend a lot of meetings, which typically leave me so frustrated I have trouble sleeping, often for days (e.g., the first couple hours of the recent roadmap discussion and pretty much any weekly Stan meeting).
So when Breck asked if I wanted every decision run by me, I said I’d like them run not only by me, but by the entire community for feedback. As an example, I keep citing the Apache 2 decision, as that’s the only big decision lately that felt open to me.
If joining the SGB the only way of influencing higher-level project decisions, I’ll probably just bow out of the decision making and stop trying to ask clarifying questions about decisions I don’t understand or seem really wrongheaded to me.
Doesn’t your proposed procedure of rough consensus involve voting over the internet or excluding most of our devs from most decisions?
Presumably whoever is involved in the rough consensus. That is, whoever’s a developer or in the community, or however that comes out. It seems like we have to do this any way. Personally, I’d like to see members of each subproject voting on that subproject and everyone voting on the project-wide decisions. Now I’d like that to just be devs, who are going to actually do the work and will be more informed about the tech used, but I can understand the desire to make it more open to
That’s tricky. And it’s going to be a problem with anything we do to decide when we’ve collected enough community input.
I think the trigger for a vote should be when we get to an impasse where we can’t make progress without a decision. That’d be tricky for things like unifying argument names across interfaces, as that’s not blocking any particular person’s progress, it’s just suboptimal for the project as a whole
I’d have been happy to write up an alternative proposal to stanfit objects (I have done it several times before) and the current one provides the model, so I think that’d be relatively easy. I assume I’d lose that vote, which I’m OK with. The only time I comment on it is when it comes around for what feels like voting again as it feels like it just did.
The Apache approach is to have a chair of each project that manages the procedure. Presumably they’d be doing it. In practice, that’d mean a tech lead wouldn’t accept a PR or would back it out if it didn’t comply.
I think we have the same problem now with people ignoring the roadmap, though I’m not clear what one could do that would violate the current roadmap. Is RStan in violation as soon as it doesn’t change its argument names to the new ones?
That seems to imply there are existing roles, which I don’t know about. I think the responsibility for executing here is on the tech leads with backup from the project director.
That’s the current status, and while I don’t like it, I’m not actively fighting against it. What I would say if you asked me before the vote went down is that if there’s a third category besides governed-by-Stan and not-endoresed-by-Stan, then it should be better defined than just saying what two things it’s not. Such as what the rough criteria are for becoming or remaining such a project.
I’d almost certainly leave any real work supporting decisions I don’t like to other people. So I wouldn’t be keen to build stanfit objects in R or Python (not that anyone would be asking me to), nor would I want to work on the services or CmdStan argument structures if they don’t get refactored the way I think is sensible.
I’m OK with the question. I think we pretty much have to assume everyone’s going to go along with whatever our governance is. I keep trying to emphasize that I don’t expect special treatment.
The real Bob is going to choose option one unless things get a lot worse than they’ve ever gotten before.
But I think the question was more about whether I’d continue to argue against decisions that had already been made by the accepted process. While I don’t want to obstruct people expressing opinions, I feel that’d be very counterproductive for the project as a whole and would certainly discourage it.