Project Tracking ================ (moderator: Emily, Patrick; notetaker: Taylor) * Emily: Patrick and I were talking about roadmap-like things sometimes this week. It would be nice if we had a list of projects that the community has agreed are good ideas. For e.g., “generally we are working on getting rid of ‘the_repository’”. * Emily: We have agreed that libification is a good thing, so anytime that someone sends a patch in that area it isn’t up for discussion whether or not the patch is fundamentally going in the right direction. * Emily: It would be cool to have a list of agreed-upon things. I also think that we should get better at figuring out what we agree on. I.e., the status-quo is argument on the list until quorum, and would like some kind of more structured way to determine when we are in agreement. * Jonathan: When you say “predictable process”, what does that actually mean? Python has PEPs, they have a very clear state machine that stringently dictates the process. * Emily: probably not something that strict, but would like to generally be able to tell “is it going in the right direction?” And approximately, “Approximately when will we be able to tell when it’s done?” * Taylor: how do we quantify that? A lot of what developing consensus looks like is developing patches and then sometimes throwing them away if/when we find a fundamental design bug, etc. * Patrick: “Are we going to do it?” is when something like a brief RFC is merged. * Taylor: Is the Git 3.0 deprecation doc a good example? * Patrick: Yeah. * Patrick: We would also want to have a document with a little check mark indicating when we are going to do small things like clean up memory leaks. * Jrn: The pain point is being able to know when making a proposal how much support they have. * Taylor: Sometimes implementation clarifies one’s thinking. * John: We have some tribal knowledge on what is accepted in which areas. Can we codify that? * Patrick: The BreakingChanges statement says that we can change things on the document if there is new information. I’d like to see that this statement is echoed elsewhere. * Taylor: It feels like it would be more useful to have a discussion based on a WIP or PoC (e.g. UNLEAK() and FREE_AND_NULL()). * Peff: I don’t want people to produce patches, say, if we blessed unit tests, and then consider that discussion immutable. That doesn’t give us the opportunity to make changes to the fundamental design. I don’t want to use it as a cudgel to shut further discussion down. * Jonathan: “I guess I am going to argue in favor of cudgel.” Taking unit tests as an example, if someone later says “I don’t see any value in unit tests”, that’s not very productive. If they say “I see the value of unit tests, but not at this cost”, it’s a more worthwhile conversation. * brian: Maybe we can only use that as an argument for 4-5 weeks. Having some disagreement is fine, just don’t want to make it indefinite. * Peff: On PEPs. Often someone will say “I’m going to go in this direction”, and I’ll feel mildly negative about it. That’s very different from voting against something. * Emily: Sure, there can be more voting options than just yes/no/abstain. * Jonathan: Apache does a nice job with +/- 0, +/- 1 (https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions) * Emily: we should be better about saying generally how we feel about things at the end of the series). * Taylor: Taking a step back for a moment, what are some examples of things that are going wrong that need to be changed? What is wrong with the project here? * Emily: things are taking too long. * Emily: Goal-posting moving, etc. * Johannes: Yes, that can be very frustrating and cause a lot of friction. * brian: When you do creative work, you get feedback and sometimes you take it and sometimes you don’t. * Taylor: at the risk of repeating what brian said, it’s hard/impossible to please 100% of reviewers on 100% of series. At some point you have to step back and let the maintainer evaluate. * Jonathan: I think the point of Patrick’s proposal is “how do you go about navigating this with a 10-series long project?” Then you’re in trouble. The proposal would allow you to check in a bullet point, or a design doc, and go through that process and navigate to the point where you get the maintainer’s blessing and the conclusion is checked in. * brian: Maybe a bullet point is too small for some things. * Taylor: so it’s a continuum, sometimes you are going to save time by just writing the patches, sometimes you are going to save time by writing out what you are doing (over a multi-series effort) first. * Patrick: discoverability! * Mark: could we encourage newcomers to email one of a few people for a particular effort (like libification) and have them comment on it? * Taylor: you might not want to centralize that much power. * Toon: How about structured errors? We agree it’s a good idea, but not on the mechanism of implementation. * Patrick: Sure, sometimes that just takes time. We don’t have to document how to fix them (maybe how to find them, but I digress). * Patrick: For structured error handling, it should be more involved. It makes sense to have an RFC or design document that documents how it’s supposed to look like. * brian: or an initial patch series that comes up with a design. * Peff: In our project, the formalism of voting is “is it merged to ‘master’ in Junio’s tree”. * Emily: I want to have the process of getting from discussion to merge be less fuzzy. * Peff: So in brian’s example, let’s take SHA-256. The process by which the maintainer decides that is inherently fuzzy. * Emily: Sure, but I would like to be obvious to someone besides the maintainer. * Jonathan: (to Peff) you mentioned sometimes you have a mild negative feeling about something and you’re good about expressing it on-list, but for a lot of contributors that will cause some discomfort and it will cause them to stay away from that thread. If we’re a little more clear about what’s expected, then conversations can get stalled less often - e.g. when a thread needs a comment from a refs expert, getting that comment that supports forward progress. * brian: I just gave Taylor feedback on the SHA-1 series that he wrote, saying that I didn’t love it. But others felt OK about it, so we moved forward. * Emily: strawman doc: https://github.com/nasamuffin/git/commit/54079ab00002c6dfa7ac1a33d9810792978d2cce - maybe it's bad enough we can poke holes and salvage something we do like * Peff: it’s important to leave at the end of your review the way you feel about something instead of just having a few comments.
