[TOPIC 10/11] Project Tracking

[Taylor Blau <me@ttaylorr.com>]

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.