Is there currently a general mechanism to override a decision by a tech lead, like a vote? Who votes? How is it triggered? There are some devs that were doing work with complex step, complex tests, and general help with the complex PR. They might be interested in seeing the PR land, but they may also have more to lose than to gain depending on how the system is set up. (My interest is in simplifying things for my employer if I should leave…) Is the vote public or private? Are there any repercussions for the voters? It seems like leads have a lot of discretion and power over devs with respect to PRs, whereas devs don’t seem to have effective checks against leads. Therefore, devs may not be willing to break publicly with leads in a vote to override due to the possible future repercussions on their own PRs, which are probably more important to them.
On intent and contributor guidelines:
I think assuming positive or negative intent on internet fora is folly, and is part of the reason why I didn’t talk about it. Clearing up contributor guidelines is not going to help if (as one short example) the PR reviewing lead is not aware that even basic things like 1.0*std::complex<var>(1,0) will not work with their preferred architecture, despite being told repeatedly. Keep in mind this was impossible to know at the time of my own PR, and only came to light after months passed and the lead tried to do his own PR and I subsequently read the implementation (because I would be stuck working around it if it passed). My PR has passing tests for all modes, including mixed mode (fvar<var>, i.e. 2nd order newton optimization), and does the promotions correctly–including with matrices to enable complex matrix math [in a sane way]. You can go down the line with inline documentation, respect of the file layout of the repo (prim, mat, fwd, rev…), actually stating what the PR lets users do, lower code surface (paths) for errors per unit of functionality delivered (higher code reuse), etc. All of those have similarly ridiculously lopsided examples in my PR’s favor vs. the other one**.
I can try to jump through the contributor guideline hoops as much as possible, but that is irrelevant if the reviewer has some kind of hand-wavy “oh we can just do ${easy} and everything will work out” in their head that does not match reality. At the end of the day, it’s impossible to compete with that. They’ll just keep inventing reasons to not approve. I don’t really think contributor guidelines can fix that. Feedback mechanisms, checks and balances: those are probably a better bet, since it is a social problem, in my view anyway.
Also, I did offer to maintain the complex implementation for 6 years, and donate $1000 to stan every time I don’t fix complex bugs within one week of report time, so add that to the points under my ‘intent’ column / tab.
**Of course, the ultimate comeback here is: do as I say, not as I do. I have no way of responding to that.
Let’s be clear. We’re not talking about boost::hana or, my personal favorite, non-constant ‘constant’ expressions. We’re talking about using the fact that a template specialization of std::complex does not necessarily share the inheritance structure of the general class template, so that we can surgically insert a layer that handles var and fvar appropriately, and then delegates back to the existing general STL (C++ standard template library of the compiler) implementation once that’s done. I also outlined another possible approach, which is to change var’s internal handling of zero, but I was encouraged by the other devs to continue with the first approach.
I think @ChrisChiasson’s experience here is an important one as it demonstrates some of the limitations that the project has slowly but surely been moving past (although we surely have much further to go).
The first limitation is the decision of whether a feature is worthy of consideration or not. This is not particularly important for small features, but it becomes critical for large, sophisticated features that require a huge amount of work to code up into a PR. Thanks to @seantalts we have been moving towards design documents (GitHub - stan-dev/design-docs) for more elaborate features – this doesn’t completely eliminate gatekeeping but it makes it more obvious, facilitates conversation from more people instead of just one reviewer, and forces an earlier conversation before any work might be wasted.
The other issue is reviewer disagreements or otherwise checks and balance against on reviewers. One of the motivations for technical working group leads was to serve as facilitators for these conversations, with any unresolvable decisions moving up to the technical working group director. Although this is still evolving, having more structure has allowed us to have better conversations in many cases and I think facilities the rapid growth of projects like threading, GPU, and compiler. Again, not perfect but hopefully moving in the right direction.
I think it would go a long way if contributor guidelines clear, explicit expectations of how a feature contributions should proceed (when is a design document needed, where and when should a conversation be started about whether a feature is welcomed) and what recourse a submitter has if they feel that the process is not proceeding fairly. We need a system that avoids comments showing up at the end of a review process, frustrating or otherwise shutting down an aging PR and pushing away contributors.
This is exactly what needs to be decided going forward.
Thanks, but not my original idea—it was part of the “do you want to block consensus” things from one of those links you sent me. I sort of take this as a default if you want to get things done with a team. The problem we run into is that as a bunch, programmers and academics are very detail oriented.
Public. No. Of course, that’s in the ideal world. If this gets so political that people can’t vote without fear of repercussion, we’ve wound up in a very bad spot.
That was by design, but in retrospect, it’s what I think was wrong. In a company, setting things up this way makes a lot of sense because everyone’s being paid to do their job and you want to move fast with coordination. In this volunteer organization, it feels very different.
Nope. Presumably everyone is working for themselves or their employer. I feel somewhat of a conflict of interest with Andrew as my boss.
That will be a consideration for any way of decision making. The same thing happens with blocs in voting. I just hope we can keep the politics as light as possible.