Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

chandlerc@hachyderm.ioC

chandlerc@hachyderm.io

@chandlerc@hachyderm.io
About
Posts
7
Topics
0
Shares
0
Groups
0
Followers
0
Following
0

View Original

Posts

Recent Best Controversial

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @boomanaiden154 @meowray

    PRs, and really leveraging all the tools GitHub gives you for PRs are another really useful bit of infrastructure.

    I think the new test setup on GitHub is already a _huge_ step here -- you need reliable CI that actually matches the expected support surface.

    Using tools like pre-commit to have CI-style checking of lots of "non test" things (formatting, etc), and to do this not in a one-off (the current formatting bots) but as a systematic thing that can easily be extended again and again to automate every step possible.

    Expand testing and CI to cover much more integration testing and system testing so that more things can be caught early and automatically. FWIW, systems like Bazel really pay dividends here... =/

    And once you have the CI automating as much as you can, tie it into a merge queue with no direct commit.

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @boomanaiden154 @meowray

    > LLVM also isn’t as good as it could be at turning contributors into maintainers interested in doing review

    I strongly agree FWIW.

    I think there are a lot of different factors here, but one I want to highlight: do folks in the community work to recognize, reward, and make it desirable to do reviews? Do they support the reviewers and create a culture than doesn't just indicate "you need to" but causes people to _want_ to participate in code review? To, literally, find joy and fun in it?

    Speaking just for myself, this (in various forms, and combined with depression and other mental health issues) is what burned me out, and caused me to pull back from the LLVM community many years ago.

    We've been trying to find a way to healthfully sustain this kind of review culture in Carbon and are having some good success. And as I'm doing better on the mental health front in the last year, I'm also trying to come back to being a bit more involved in LLVM. In large part, my goal and what I want is to figure out how to help nudge the culture in this direction.

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @meowray @boomanaiden154 @shafik

    I'm not just describing something that is purely hypothetical or theoretical. There are open source projects that are (IMO) doing are fairly effective at striving towards this. For all of its failings, the Linux Kernel IMO does a decent job of this specific thing. I think both Rust and GCC are doing a bit better than LLVM with this specific aspect recently, although both still struggle somewhat. I think various parts of Go (but maybe not all of it) do pretty well here, etc.

    I also think a (much) bigger challenge than institutional incentives is the culture established by the leaders in the community: do they prioritize this? Do they do so in way that shows empathy, and makes people _want_ to join them in the effort? Do they bulid buy in with others in the community so that the _entire_ culture shifts in this direction?

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @shafik @boomanaiden154 @meowray

    I think the key thing I would emphasize is to attack the meta-problem rather than your personal ratio here -- how do we create a culture and community that _consistently_ pushes for a healthy and sustainable balance. That's where I think individuals can make the most difference here.

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @boomanaiden154 @shafik @meowray

    FWIW, I actually don't think the incentives are that hard to align here.... I think the problem is that we've gotten burned by a tempting but implausible fiction of prioritizing patches over review / maintenance / building community. I'm being completely genuine when I say this is tempting, and incredibly hard to resist. But I think that culture is the dominant factor here, and with the right culture, the community can establish and uphold the necessary incentives.

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @shafik @meowray

    I still think the key is the cultural prioritization of balanced contributions between new patches and review.

    But I completely agree that sustaining that cultural prioritization without _significant_ funding so that people are actually paid for these balanced activities is almost impossible for large projects. And this kind of funding means either sustained long-term commitment from large corps, or something like Igalia, Lenaro, RedHat, or a dedicated foundation.

    However, I think LLVM _has_ this kind of long-term large-org commitment. But it has struggled to channel that commitment to some of the needed code review and maintenance needs of the project. We're actually making good progress on changing this within G, although still lots to do. But I want to point out that this won't work with one or a few organizations -- the entire community needs to embrace the culture shift, _and push large orgs to uphold it_, for it to succeed.

    Uncategorized

  • Quality, Velocity, Open Contribution — pick two.
    chandlerc@hachyderm.ioC chandlerc@hachyderm.io

    @meowray FWIW, strongly disagree here.

    I think it is entirely possible to have quality, velocity, and open contribution.

    I'm not saying there isn't a tradeoff, but I think the above three can be preserved sufficiently.

    For example, in LLVM, I think the bigger challenge than quality is that people view "contribution" as _much_ more about "sending a patch" and not "reviewing a patch. As a consequence, the project has lost community and cultural prioritization of code review as an active and necessary part of contribution.

    Also, "open contribution" doesn't mean you _have_ to accept contributions. I think a project can still have meaningfully open contribution while insisting contributors balance their contributions between patches and review, and where contributions that are extractive are rejected until the contributor figures out how to make them constructive.

    IMO, criteria for sustaining both quality & velocity in OSS:
    - Strong expectation of _total_ community code review in balance to _total_ new patches -- this means that long-time contributors (maintainers) must do _more_ review than new patches.
    - Strong expectation of patches from new contributors rapidly rising to the quality bar where they are efficient to review and non-extractive.
    - Strong testing culture that ensures a large fraction of quality is mechanically ensured
    - Excellent infrastructure use to provide efficient review and CI so tests are effective

    I think LLVM struggles with the first and last of these. The last is improving recently though!

    Uncategorized
  • Login

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups