Add new developers!

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:

  1. Being a core team member listed on https://mc-stan.org/about/team/
  2. Having permission to accept PRs in a given domain area
  3. 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.