[TOPIC 10/12] Project management practices

[Taylor Blau <me@ttaylorr.com>]

(Presenter: Emily Shaffer, Notetaker: Jonathan Nieder)

* high hopes and low expectations! Let's play nice
* Project management related tools and practices we may be used to from $DAYJOB
   * Bug trackers
   * Long-term and short-term project planning
   * Roadmaps
   * Documented project direction
   * Tools, like wiki
* Some things other open source projects do
   * Some do things like two-week sprints with contributors, more structured
   * development of some features
* Some things that happen in regular workspaces
   * Ad hoc whiteboarding through a problem
   * Live chat with history
      * We have IRC but it's dwindling outside of IRC standup
      * There's informal discord
* Lots of tools! Are there ones we want to get benefit from?
* Example: bug tracker
   * Lots of interest, but don't have a shared understanding of what we want
     from a bug tracker
* If you could pick something from your day job and apply it to the Git project,
  what would you look for and what would you want from it?
* (Taylor) "Let's have a quick VC"
   * All being at the same organization within GitHub, people are very willing
     to just jump into a Zoom meeting and talk through a thing, whiteboard
   * There's benefit to having things documented on-list, but I think we could
     walk that back a little
   * (Emily) One thing I've liked with the contributor summit and similar events
     is sending something to the list so people who weren't there can still
     follow and respond
   * Would "Taylor and I just talked about cruft packs" emails be something we
     want more of?
   * (Taylor) Yes and no. Sometimes a conversation is for getting ideas,
     sometimes for making a decision. They deserve different approaches.
   * (Emily) By the way, I've been surprised at how open people are to VCing
     when I try it. Conversations about cruft packs, conversation about config
     based hooks series, tried "let's have a VC" and Ævar was very open to it in
     that example and it worked well
   * So it might be something we should just try more often
* (Emily) At a Git contributor summit, some attendees mentioned wishing they
  could see a published Git project direction
   * Various companies are putting dedicated time into the Git project, and
     those aren't published anyway
      * Page with "GitHub cares a lot about cruft packs, here's how you can
        help"
      * Is that something we could write down somewhere more static than the
        mailing list?
   * (Junio) How quickly would that become stale?
   * (Emily) It depends on how you build it into your own processes. Every
     quarter we write quarterly objectives and key results for my team, publish
     that to everyone at Google. I could also publish that to the Git mailing
     list, part of that normal process could be posting it on a Wiki page.
   * (Jonathan Tan) One thing I'd find difficult in publishing such a thing is
     understanding the priority of line items. Currently I learn about people's
     priorities from patches and from what they say in venues like a contributor
     summit
      * Contributor summit is once/year, if you're saying something, it's
        probably important to you
   * Things that change once/quarter are harder to judge. How much are you
     dedicating to them?
   * (Taylor) Suppose this existed. What would people use it to answer? Mutex?
   * (Emily) There have been some good cross-company collaborations in the past,
     such as partial clones. Noticing the opportunity to work together on such
     things is the kind of thing I'm thinking of.
   * (Taylor) Back in 2014-15, GitHub had an awesome tradition of there being a
     "radar issue", people could comment on this big long thread on what they
     want to hack on.
      * I think that's a little different than publishing a committed roadmap,
        with pressure and accountability. "What is Jonathan Tan interested in"
      * Could be as simple as every quarter we send an email to the list and all
        reply to it.
   * (Jakub) We can attach a roadmap to the same place Git Rev News[c] is, you
     can get news and a roadmap in the same place.
   * (jrn) Sharing your plans and priorities helps people know what they can
     expect you to care about. E.g. if your work is all reliability, all the
     time, maybe a new UX change is not as exciting right now, versus
     reliability focused work is a good place for collaboration.
   * (Calvin) Having timestamps, e.g. a pinned message on Discord, helps you
     know if something is stale.
   * (Jeff Hostetler) Make a repository, publish there "I'm working on this".
     Send a pull request, get feedback. Nice and compact, has timestamps, stays
     in our ecosystem.
* (Emily) I don't like the trend of projects being only managed on discord. But:
  I'm wondering, what changes would make the git community discord more of an
  official channel in the same way as the git mailing list is?
   * https://discord.gg/aUCkDVUqqu
   * (Elijah) There's a Git Discord?
   * (Taylor) We just needed to make Elijah aware of it. ;-)
   * (Jeff Hostetler) I think discord is a bit childish, git repos are something
     professional we all use every day.
   * (jrn) There's a bit of a shift IRC -> Slack -> Discord in a lot of projects
   * (Emily) A big benefit of IRC is that it's a decentralized protocol. Having
     a part of our infrastructure be a centralized, nontransferrable thing is
     scary to me, but maybe there are technical ways to address that. Export
     logs, matrix bridge to IRC, ?
   * (Taylor) I think a barrier to use of chat can be fear of decentralization
     of information, it's convenient that the git mailing list is a one-stop
     shop
      * (Jeff Hostetler) +1, having too many things to check
      * (Emily) I think this is also why we're hesitant about other things like
        bug trackers etc
* (Jonathan) Bug tracking
   * (Emily) This year we moved crbug.com/git (Monorail) to
     git.issues.gerritcodereview.com. There's 80ish issues there. Our team
     within Google uses it. But of course in reality no one else is making use
     of that issue tracker. If there were somewhere else to put bugs instead,
     we'd use it - I don't think it's too important where that is, as long as we
     can do it somewhere.
   * (Junio) Someone needs to curate it.
   * (Emily) It would be possible for us to curate, triage
     git.issues.gerritcodereview.com if people start using it.
   * (Junio) Not limited to bugs, but we from time to time talk about other
     aspects of tracking. Things like patchwork. We talk about mechanisms, but
     not so much about enforcing use of those mechanisms.
   * One work practice I like at work is that anyone can write a CL, and then
     people are forced to review or look at the patch in a reasonable amount of
     time.
   * It can be frustrating as a maintainer, because I don't want to be reviewing
     and looking at all the patches on the list myself. And I don't like having
     to queue patches not looked at by anybody.
   * (Emily) This makes me wonder if we should be having conversations about
     things like "whose turn is it to take action on this patch".