Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Together for a healthier Clippy | Lobsters
[go: Go Back, main page]

  1. 85
    Together for a healthier Clippy rust blog.rust-lang.org
  1.  

    1. 35

      TBH, I found the link in the post to Bevy's open review process, which was posted here before and didn't draw much discussion, even more interesting than this announcement. That is a really thoughtful, smart approach. I'm glad it works and am not surprised. I hope Clippy sees similar results.

      1. 14

        Hey, I posted that article! I used to be a pretty active contributor to the Bevy game engine, and quite enjoyed their review process. The system incentivizes small, incremental PRs, as they are much easier for anyone (even first-time contributors!) to review. Large PRs took much longer to merge, as they should, because they are harder to review and require a certain level of familiarity with the code. Often it was maintainers and subject matter experts who pushed the large feature-ful PRs over the line.

        If you enjoyed that article, you may like some of the author's other works about maintaining Bevy: Triage-by-controversy and community review and The Tyranny of Nits!

        1. 5

          Thank you for sharing those. It's cool to see how much thought has gone into the process. No wonder Bevy is getting so good. The release announcement a few weeks ago finally put Bevy on my radar as a thing to try, and it's really nice to use so far. Between being nice to use, interacting directly with its source as a matter of normal usage, and having a friendly well-considered contribution process, it seems natural for it to attract a large pool of contributors.

        2. ~

          While I haven't contributed to Bevy, their working group structure seems to have produced good results since it was implemented.

        3. 19

          One of the reasons why I don't help with reviewing PRs for the open-source projects I contribute to is that I don't feel legitimate due to having very little expertise. Clippy's (and Bevy's) process legitimizes less experienced reviewers, which is pretty neat in my opinion.

          1. 7

            Not quite what I was expecting by reading the title...

            1. 8

              Yeah, the article does not make it clear what Clippy actually is. Turns out it’s a Rust linter.

              1. 16

                It says it's a linter in the article (albeit at the bottom) and it's at Rust's website. They could have made it clearer, but I'm assuming the intended audience is the Rust community

            2. 3

              This seems easy to game by using a few accounts and submitting PRs across them all. I'm not sure what's to gain from gaming it, but being on a secret list of cool contributors seems an incentive.

              1. 19

                In Bevy's review process (which inspired this), it is very common to "trade reviews." You and another contributor review each other's pull requests, and in turn they both get merged faster. While this thrived best when the contributors are working on the same project, I've seen it done on unrelated work as well. I hope Clippy develops a similar practice, as review trading gets work merged quicker and fosters a collaborative community.

                I think the paragraph in this blog post introducing the review mechanism could be improved. Right now I read it as "if you skim another PR we'll merge yours faster," which I don't think is the intended message. Instead, I think it should focus on working together with other collaborators. Tell people to go to Clippy's Zulip channel as offer to trade reviews, get them to work together on the same project, and you'll develop a healthier community without incentivizing gaming the system.

                1. 2

                  I had similar thoughts. An unfair participant could make up fake-features with their sockpuppet and get "real maintainer attention" for my real account.

                  Both should be rather easy to avoid with the following

                  • the review pairs are random. People should not review the same person's work multiple times
                  • Only count reviews for PRs that end up being merged.
                  1. 6

                    If the reviews are legitimate, I don't think there's much of a problem.

                    Though, I wouldn't want a contributor introducing bugs into their own PR and pointing them out with a sock puppet. If we catch that kind of behavior, then it'd be dealed with by the moderation team.

                2. ~

                  I have a service for this (help reviewing PRs and issues of others). https://www.CodeTriage.com.