1. 18
  1.  

  2. 6

    Myself I think a “good first contribution” label can be a good thing. Maybe there should be a “bad first contribution” label instead, if “good first contribution” attracts wrong kind of people (I’d like the author to elaborate what kind of wrong people it attracts).

    What I mean by “good first issue” is that the implementation is straightforward and free of pitfalls. There’s a kind of issue where implementation seems easy, but naive approach will a) interact with other subsystems in a bad way b) break compatibility with older versions c) only fix a symptom of a deeper underlying problem d) all of the above.

    A good first issue is one that isn’t a can of worms.

    People may also want to “test the waters” before contributing a patch for their real itch and contribute a simple patch to learn about development procedures and standards of the project and see what interaction with maintainers is like, before trying to contribute a big change requires for their own needs.

    1. 1

      I like the reversal of tagging. “Bad first issue” leaves it clear that “you are not expected to be able to fix this” whereas “good first issue” drives away experienced patchers, and leaves novices with no clear idea of how to fix

      1. 1

        In the VyOS bugtracker we actually have multiple difficulty levels from “Easy (less than an hour)” to “Insane”. Many people don’t bother trying to fill it though.

        1. 1

          That becomes a knob rather than a single optional button. A single tag is more like leaving a note “I wasted hours, learn from my mistakes” rather than more work “first you’ll need to do….”

    2. 5

      #1

      I don’t like when maintainers have higher standards for contributions than what they’ve already written.

      Backstory: I once tried to contribute a fix something incorrect in a popular Rust project. My PR turned into maintainers discussing how to come up with a perfect solution, which made me lose interest. Today, the code is still incorrect.

      What’s more important to you - fixing incorrectness, or applying more stringent requirements on contributions than you applied on yourself when writing something incorrect in the first place?

      #2

      Projects that have no contents. Take a gander at this: https://github.com/mdlayher/xdp

      According to the description:

      Package xdp provides access to Linux userspace XDP sockets (AF_XDP). MIT Licensed.

      Does it do this? Not even close. This thing has github badges, but no working code. It has a motherfucking travis CI file, but no working code. What the fuck?

      I’m most ashamed of the period of my life where I was sucked into a stupid vortex of README.mds and GitHub star/badge races instead of actually writing code that did the bare minimum of what it promised.

      Also, don’t take this as a personal attack. I’ve been (and still am) guilty for all of it.

      1. 3

        don’t like when maintainers have higher standards for contributions than what they’ve already written.

        This has happened to me a lot. Contribute a fix/feature, maintainer(s) bikeshed on things they didn’t even do in similar areas in the project. Great way to discourage contributors.

        1. 2

          I don’t like when maintainers have higher standards for contributions than what they’ve already written.

          I think that’s a difficult balance to strike. I find that my standard for the code that I write for a project often goes up over time. When a project starts, I may be willing to commit quick hacks that get something working with a note to refactor it later, but once it’s vaguely mature I want new contributions to come with tests, docs, and so on.

          That said, I find that it’s a good idea to apply the MVP model to PRs: what is the absolute minimum that you’re willing to accept, can you get this in and then let them work on the other improvements later? You can always back out a change later if you approve one PR and ask for other things in a follow-up and the original PR’s author loses interest and doesn’t get back to you for six months. Or you may find someone else wants to do it: open an issue for it and see if anyone else picks it up.

          1. 1

            I enjoy the contribution mechanism advocated by Pieter Hintjens, where you require a commit message format of Problem: Solution: and if the format is kept and the Problem: is a problem you want to solve, the commit is merged. That way all real contribtions are fast pathed in, and bad contribtions become a matter of record, and people can be blocked in the future for malicious contribtions.

            This talk is worth the thirty minutes: https://m.youtube.com/watch?v=xFVDNTXIC_Y