When we were working on the Intro to Open Source course, one of the biggest painpoints we noted with new contributors was the frustration they felt...
For further actions, you may consider blocking this person and/or reporting abuse
this is about transparency and communication. When someone adds a feature the question is, is it required?
For Resume Matcher, many times if someone does a PR I ask them to share why they've done that or if someone wants to contribute what kind of changes do they want to do before they get the PR done. And the communication happens in Discord community for us. This way we know why there'a PR, what changes does it targets and gets it merged in time.
When I suddenly get a PR with a lot of change, from someone who I've never interacted with. That's where things get tricky.
For sure. And this is where things like READMEs with clear contribution outlines can be helpful (start with an issue, if it's an architectural change, you need an RFC, no unsolicited PRs. It'll never be perfect, but you can definitely find ways to decrease the number of unwanted PRs.
These days many PRs are just automated via Cursor, GitHub Co-Pilot, etc. And eventually bring in a lot of change in the code. It's very hard managing and yes, READMEs need to convey this message clearly. Do you think having a contributions section on docs would help @bekahhw ?
At the very least have a basic Contributions section on the docs and include the most important information. We have a pretty extensive CONTRIBUTING.md file at Virtual Coffee to help new folks navigate the process for contributing.
I know a lot of people are dealing with the automated PRs, and it's a real struggle for maintainers. I think having a bit of friction can help with that, but won't solve the problem.
For instance, using PR templates with a field that says something like:
AI-generated PR check
In this projects, we understand the value that AI can bring to code. However, we will not accept PRs that have been automated by AI and not reviewed by the PR submitter with a clear understanding of the changes, impacts, and maintainability of the code.
Did you use AI to generate any of this code?
If you answered yes, please answer the next question:
Did you personally review and understand all AI-generated code in this PR, including its purpose, impact, and long-term maintainability?
And then have a GH action that automatically closes the PR if they select No to the second question with a message:
This PR is being closed as an AI-generated PR. Please feel free to resubmit once you understand the purpose, impact, and maintainability of the code.That might be too complicated. Kind of thinking aloud here.
Yes this is helpful, what I've done recently is setup CodeRabbit and if someone doesn't fixes the obvious bugs in the PR, then it's a no-go from my side. For Resume Matcher.
Awesome. You might want to check out pullflow.com/ (from the collab.dev team). It might be useful for your workflow.
Okay π
Thanks ^_^
This hits home - I've had PRs sit ignored for weeks, and that silence is rough. Do you think collaboration-focused metrics will ever replace stars and forks as the 'first impression' signal for most devs looking at a project?
That's a great question. I think it would take a couple of things for that to happen:
I really would love to help with any open source project at some point, I feel like it's a duty, but unfortunately for now I can't really, though I will be free and able to write code without looking at clock again and again pretty soon, and will probably try to help an open source project that I think I can help by any mean, so I really appreciate your post giving more clear vision about situation!
Itβs definitely a balance. And I think itβs better to wait until you have time to give back, than try to when youβre limited
been cool seeing steady progress - it adds up. you think the real growth for these projects comes more from systems or just people showing up every day?
As for most things in technology, I think it depends. You definitely need people to show up everyday. One of the big things is also having the right people show up. You can have ten contributors, but if 1-2 of them aren't good communicators, listeners, and/or collaborators, you're probably going to be getting less done than if you had 2-3 right contributors. As projects scale, you definitely need to have solid systems built.
This is such an important conversation....metrics should reflect the human side of open source...not just numbers.
Always the challenge, right?
yup.
This post needs more visibility for sure. Here is the comment for the algorithm.
I appreciate that!
Another great article Bekah!
There were so many things here that you mentioned that resonate with what I have been experiencing as a maintainer for freeCodeCamp.
Thanks so much, Jessica! It's nice to be talking about open source again and thinking about the collaborative aspects.
Totally agree β stars and forks donβt tell the whole story. We need better ways to measure real collaboration and community impact in open source.
Absolutely. I think there's a lot of progress being made, and I really appreciate the approach collab.dev is taking.
I've run into your core statement recently. Working at a company that has an open source project as part of it's DNA we're thinking through how do we measure "success" of that project? Do we have to have telemetry? Is it contributors? Stars? There's the marketing aspect of it where people will evaluate a project based on downloads and stars but also the maintenance aspect over time. You bring up very interesting points around collaboration patterns as a measure for an open source projects health.
Thanks, Seth. I've written pretty extensively about the metrics that matter. A lot of it depends on your goals. Ultimately, keeping your project secure and resilient should be at the core of your goals. Stars are not going to tell that story. Understanding collaboration metrics, if your team is resilient against the lottery factor, having an SBOM, are really great ways to get started. Happy to answer any questions.
Impressive