Hi Martin,
On Fri, Sep 29, 2023 at 08:27:43PM +0200, Martin Roth wrote:
# New Contributor Hashtag # Greeting new users
Sounds good. Not sure I can add anything here other than:
Here's a sample greeting:
If you would you like someone to take over your patches at any point, please just post a comment to that effect on the specific patch.
Would a comment like that on a random patch actually get noticed by anyone?
# Maintainers list
As mentioned previously, we have a list of maintainers for various areas.
Unfortunately, we don't have a maintainer for the SPI code, so we don't have anyone who has said they'll take responsible for reviewing a number of your patches.
Additionally, the people who are on the maintainers list frequently maintain a LOT of things simply because we don't have enough really experienced people to review everything that gets pushed. I'm honestly overwhelmed by the number of reviews I get added to. I think I have over 300 in my queue right now.
I like to philosophize about incentives. So what incentives does a contributor have to get themselves added to that maintainers list?
The cynic in me says: none. It's just hard work nobody wants to do, but that doesn't explain the fact that there are in fact plenty of mostly-volunteer projects with a thriving development community.
My current theory is, this happens when people see some kind of social reward for doing that hard work.
As I see it most review systems designed for use by companies dehumanize the experience too much. Remaining an employee is usually plenty of motivation for people to put up with these systems. However when you want to attract contributors from outside that context this friction clogs up your funnel.
The email-based git workflow (which GH copied fairly well) does things right here by having the "default" be for people to get notified of all project activity and sending reviews being as easy as an email reply.
This paves the way to anyone becoming a maintainer/reviewer simply by being one without needing any "permission".
# Gerrit as an issue
You mention that you see gerrit as a problem, but don't think the issue is gerrit. My guess is that you're simply not familiar enough with it to use the features it offers properly - This isn't meant to be a slight towards you, there is definitely a learning curve.
If you click on any of your patches, you should see a section called "Relationship Chain" generally in the upper middle right of the page. That's the patch train, in order. The first page that you see is simply ordered as the list of patches most recently touched in some fashion. It's not meant to show any sort of relationship.
Oh I've gotten plenty familiar with it ;)
The random order I'm talking about is on the "topic" search results page I've linked to before. I just find it problematic that a potential reviewer wouldn't even really easily know where to start with my series without jumping through hoops or me telling them :/
Say what you want about the gitlab/github model, but at least they display patch series in-order :]
Were I a committer I'd probably also be peeved by not being able to merge a whole series at once, but I assume there's a mechanism for that?
# We need ideas on *how* to improve
It's fine to say that the coreboot project should "do better", and you're not wrong, but without something concrete that we can actually do, that's not something we can just agree to do.
It just so happens I have opinions here, but frankly I'm the worst person to ask as I don't know the project or community intimately.
The coreboot project does not have any paid employees to do the work, and without getting significantly more contributions to support someone, I don't see that happening anytime soon. There are a number of companies supporting work for coreboot, but they're all supporting engineers responsible for their particular sections. Any work done in other areas for the community good, is generally done by volunteers. Asking unpaid volunteers to be strictly responsible for things is difficult. This is a problem that many open source projects have.
A common problem indeed, more so in projects where commercial entities participate directly through their employees rather than mainly through "independent" individual contributors in my observation.
cf. Debian or Linux. DDs/Maintainers have quite a bit of leverage against employers in the "my way or the highway" kind of sense.
# coreboot Leadership Meeting
I'd really like to ask you to attend the leadership meeting - we hold it every two weeks. You can find the time and how to join on the coreboot calendar: https://coreboot.org/calendar.html
I'm not sure that's the right venue for this discussion at this point. Perhaps more of a hallway track discussion for the next conference (37C3/FOSDEM anyone?).
--Daniel