I would like to add a few people to the dev team. There have been a few people working on the Math that I’d like to recognize and invite to the team officially.
@seantalts, how should we proceed?
5 Likes
I already added Andre Zapico. I went to look him up on the dev list and was surprised he wasn’t there. I hope that’s OK!
1 Like
There are a few more people that I’d like to add to the Math developers list. I’m looking for guidance on what our policy is. If it’s up to me for the Math library, then I’ll put up some broad guidelines for including developers to the Math library and keep it up-to-date.
The proposal I left off with was that the tech lead of each module was responsible for adding new devs once they’d made enough contributions. The critierion was nominally merging a non-trivial pull request.
That’s why I was technically overstepping my authority with Andre Zapico, but figured it would be uncontentious given the criterion of contributing. I just reminded @seantalts and @jonah about a few people I think they need to add. In the future, I’ll stick to pinging the tech leads. I just added Andre without thinking too hard about process and only in retrospect realized there had been a half-baked policy in place (half baked in the sense that I suggested it, but didn’t get consensus on implementing it). Before that, I’d been the one adding almost everyone because I think it’s important to recognize contributions.
Oh, sorry for not seeing this before. I think what Bob said sounds good - having had a non-trivial pull request merged and that area’s tech lead vouching for them.
What do you all think about instituting a private developers-only nomination period a week long in case anyone wants to speak up about the potential new core team member. That period would allow anyone in the core team to speak up privately in case there are any known issues with that person. I’m thinking that would mostly be helpful as a catch-all screening time for things around previous violations of codes of conduct or bad judgment, that kind of thing.
Also, this might be a good time to talk about the differences between:
- Being a core team member listed on https://mc-stan.org/about/team/
- Having permission to accept PRs in a given domain area
- Having permission to accept PRs in a given language
What do you guys think about potentially splitting that up some? I was reminded today because at Google a developer can be permissioned with “readability” approval on a per-language basis and I think separately technical on a per-project basis and I think you need to have both bits flipped for a given PR before merging. Might give some structure to informal notions I often feel when I say things like “I can look at this code and see if it makes sense structurally but I don’t know the math here well enough to feel good about approving it.”
1 Like
What I’d like to see is some common guidelines that we have across all of Stan.
For each repo, it seems like we should start having:
- tech lead(s)
- maintainers
- PR reviewers
- developers
What’s expected at each level? What’s the benefit for the person at each level? Does the tech lead automatically get invited to the TWG? At what level does someone get added to the Stan develpoment team (if that’s a centralized team)?
What guidelines do we have for adding new projects?
What about removing projects or people?
I don’t think this should be left up to each repo to decide, but if that’s what we want to do as a TWG, then let’s make that a reality so we can move on.
Is it important to have common guidelines?
That was just me repeating someone else’s proposal. ’
We talked before about just letting users use their judgement, which is what most open-source projects do that aren’t run as a dictatorship (benevolent or otherwise). My main worry is that I think it’s going to be hard for us to start vetting and badging people.
How’s a maintainer different than a reviewer? In the past we discussed tech leads (still unclear on role), reviewers (permission to review), and developers (GitHub credentials for stan-dev and ability to vote on Stan governance).
There’s a TWG director, but as far as I know, there isn’t a TWG.
Neither the role of the TWG (aside from the director) or the tech leads have been spelled out. The only official word I know of on @seantalts’s position is this:
If there’s more than that somewhere, please let me know. That post includes this:
The director will operate with a set of clear but high level goals from the SGB to be drafted and voted on separately.
but I do not believe the SGB has laid out any goals. If they have, please let me know where to find them. It also includes this on the tech leads:
- Setting a technical vision and roadmap by acting as the product manager and (re-)negotiating the priorities and technical direction with the TWG leads according to the mission and goals set out by the SGB.
- Act as final judge interpreting the SGB mandate and stakeholder needs to break ties and settle disputes between tech leads.
I think what this document calls “TWG leads” is what everyone’s caling “tech leads”. As far as I can tell, it doesn’t lay out any responsibilities or authority for these tech leads nor does it indicate how disputes will be settled.
There’s nothing in there I see defining the TWG itself.
I also think this needs to be clarified:
- Last-resort, rarely used veto power over any technical decision affecting the
stan-devgithub projects.
It seems to imply someone other than the TWG director at some point is making technical decisions that can be vetoed.