And I will now like to introduce our next speaker to you.
I would say he needs no introduction because you're already running his code.
But he might need an introduction.
This is a new...
Sorry, could I have some silence in the room, please?
Thank you.
You're already running his code and he's telling a story of which I am, for some reason, after
running the Go Dev Room for five years.
Still I'm curious about, because I haven't contributed the Go project yet.
And he has.
I'm jealous of him.
So round of applause for a Go contributor.
Thank you.
Can you hear me okay?
Is the microphone on a good spot?
Yep.
So quick show of hands.
Who here is a Go contributor?
Is contributed to the standard library, the compiler.
I see one, two, three, four, shows hands, five.
Who here would like to be, like Marcia, who would like to be a Go contributor?
There's a lot more hands.
Who of you who wants to be is afraid to become a Go contributor?
Who thinks it's intimidating or complicated or you just don't know enough about Go routine
scheduling or something like that?
Okay.
This talk is for you folks who have your hands up right now.
So my goals for the talk...
Oh, first of my agenda.
I'm going to talk about goals, who I am, and I'm going to tell my story of how I became
a Go contributor and talk a little bit about how you can too.
So that's my goal.
My goals today, tell my story.
And ultimately to encourage you to be less intimidated about becoming a Go contributor.
My non-goals are to be exhaustive.
I'm not going to do a deep dive into how the proposals work or how Garrett works or all
the technical stuff.
And I'm not going to show you a lot of code.
There's a little bit of code, but you don't even have to be a Go developer to understand
the code I'm going to show you.
Who am I?
I'm a Go contributor, technically.
I'm a fractional Gofer.
Fractional CTOs are all the rage these days.
I'm not that.
I'm a fractional Gofer.
I work for different clients.
You can hire me if you want some help with your Go.
I also do Go mentoring and career mentoring, hire me.
I'm also the co-organizer of the Go Amsterdam meetup.
And I'm a podcast host and YouTuber.
I hit that word, but I put videos on YouTube, so I am one.
So some of you may know me through the Cup of Go podcasting.
Listeners here in the room today?
All right.
A couple.
I hope there's a lot more after this.
I have stickers, by the way.
They'll be over there.
If you like Brewster, our little Gofer mascot for the Cup of Go podcast, get a sticker for
your laptop a little bit later.
So how did I become a contributor?
Well, first I needed an idea.
So long ago, I wrote this public open source library called Kivik.
It's for CouchDB.
It's sort of like database SQL, but for CouchDB.
So if you wanted to be document store stuff.
And I had a request from a user of my library.
They were trying to send a regular expression as JSON to CouchDB because it's a JSON store.
And it was just submitting an empty object rather than meaningful data.
So they said, hey, could you make your library do this thing the right way and send a regular
expression string?
It's like, that's a really great request, but I don't feel like it's my library's
responsible to do that.
That should go in the standard library.
So I created a request, which we'll talk about.
But first, here's the problem they were explaining.
So here's the code.
I think this is the only slide in the presentation of code.
So imagine you have this regular expression, food question mark.
So it would match fo or foo, pretty simple.
And you call JSON Marshall on something that contains that.
This is the output you would get.
Not very useful.
This is the output the user of my library wanted and what I thought made sense.
So I created a proposal on the Go issue tracker on GitHub.
Now this is a great point to mention that there is a process, a proposal process.
Some of you are probably familiar.
If you listen to the Go podcast I just mentioned a couple of Go, we talk about proposals fairly
frequently and we talk about, oh, this one's in the accept phase or this one's been declined
or this one is possibly accepted and so on.
That's all relates to this.
Now this is a very simple proposal, so it didn't need the design doc, which some do,
like generics had a design doc, actually multiples of design docs in the end.
So this is a very simple proposal.
I mean, I just explained it to you.
I don't need a design doc to explain what I just explained on the last slide.
So this didn't need that.
So I just created a little, you can see there, that's the entire issue there, right?
That's what I wanted.
I showed the code that I just showed you.
I showed the current behavior, the expected behavior and a little bit of conversation about
my reasoning.
And so that happened in 2021, May 13, if I can read that correctly.
And then that kicked off this proposal process or a truncated miniature version of it anyway.
So we had some discussion.
One of the first comments came from Daniel Marti, who said, this would also be useful
for this other thing and tagged Joe Sy, who was working on another issue that it would
be relevant to.
I don't know who this person's name, I didn't look it up, but they said, losing the options
feels like a deal breaker.
What that was referring to, there's actually two flags you can put on a regular expression
in the Go library.
You can say it's a POSIX regular expression and you can say it's, is it longest match?
So at the end of two Boolean flags you can set on a regular expression and those are
not expressed when you call the dot string method on the regular expression.
So those flags would be lost.
And so this person said that feels like a deal breaker.
And there were some other comments too, but ultimately Russ Cox came in and said on June
9, so this is almost two months later, said it looks like this is probably going to be
declined based on the fact that it would be a lossy expression of the regular expression.
That was sad.
Not really sad because this isn't a feature I wanted, I just was kind of excited to see
a feature I proposed, you know, get through the process.
And then Roger Pepe, I think is his name, came in and said, I think it would be fine
if we went ahead and did this.
You know, just use the equivalent of string, it's already lossy, why don't we just go
with that and so on, gave his reasoning.
And so this is just a month later now, we're into July 2021, Russ says, so this is the
current idea, we're going to have Marshall and un-Marshall do exactly the same thing
that string does, blah, blah, blah, and then it looks like it's going to be likely accept
now.
So, cool.
Happy about that.
Fingers crossed, let's see if it really becomes accepted.
A week later, no change in consensus, so it became accepted, yay.
So who's going to do the work?
Sadly, just having your proposal accepted and go doesn't mean it's done, someone has
to actually do the work.
Now this isn't a lot of work, in fact Russ said, even before it was accepted, I'll do
the implementation and see if I come up with anything surprising.
I don't know if he ever did, if he did he never mentioned it on the issue tracker.
If I ever had the chance to interview him, I'm going to ask him, did you ever do that
thing?
So I said, January, this is six months after it was accepted, I said I'm interested in
working on this and nobody really responded except somebody gave me a heart and I thought
I felt good, but.
And then three months later, four months later, Joe Sy says, hey are you going to do this,
Russ?
I can actually use it now.
And Cricket's from Russ, he's a busy guy, no shame on him, but you know, so more weight
eating ensues.
So I decided I was going to go ahead and do it and I decided to, I don't remember exactly
when, we'll see the dates in a few moments, but so I decided to go ahead and do the code.
Now this is a good time to talk about the contribution guide.
This is probably the part, at least I felt, was the scariest part of contributing to go,
so I'm not going to talk in detail about it, but the TLDR is you have to create a Google
account, you probably already have one unless you're intentional about not having one for
security or ethical reasons or whatever.
If you want to contribute to go, you have to have one, I'm sorry to say, so if you're
avoiding that bandwagon for ethical reasons, maybe go, contribution isn't for you, I understand
your reasons, but you have to have a Google account, you have to set it up a Garrett account
with a Google account.
What's Garrett?
Who's used Garrett, I'm curious?
Who doesn't even know what the word means?
All right.
So think of like GitHub except an open source version of GitHub from 1992, that's what it
looks like, but it's really powerful in ways that I can't really comprehend or explain
because I haven't used it that much, but it's not bad, so don't be afraid of it, but they
use Garrett for that.
Now actually I lied a little bit, they do use Garrett for that, but you can do this through
GitHub also, and I've not done that process, but if you're really afraid of Garrett and
you can't read the documentation and follow the instructions, you can also use it, create
a GitHub pull request, so that's an option open to you if you're really afraid of this,
but don't be, it's not that bad.
So 11 months later I finally wrote the code, I created my Google account and all that stuff
and the Garrett account and I wrote the code, this is my change, this is what I added to
the standard library, plus some tests and a couple other metadata things.
It's like 20 lines of code if you count the comments in the blank space, the blank lines,
that's not a big deal.
I was really hurt though that Marcia didn't mention this in the Go 121 changes because
I know it just barely threw under your radar.
I actually got this yesterday evening, you're going to find it.
Yes, yes, okay.
And you knew I was going to talk about it, so why mention it twice?
So really simple, I guess I lied, there's two slides of code, but it calls the string
method and turns it into a byte slice, that's all it does to Marshall, to Marshall, your
regular question, and then to un-Marshall it, it does the same thing in reverse with an
extra error check, super simple code.
So I pushed that up and then I, this is a screenshot of Garrett by the way, like I said,
1992 GitHub, that's what it looks like.
And I got some code review.
And then it was time for some humility.
I kind of pride myself in writing tests and writing good tests, I usually write them before
my code, first comment, make sure the test pass.
I failed to, I mean I tested my code but I didn't run the entire test suite, which takes
10 minutes or something on my machine, and it was failing.
The reason it was failing is because I failed to add some metadata about public API changes,
it wasn't a big deal, it was easy to fix, but it made me feel a little bit silly for
like, not writing, not running the test suite before I asked other people to waste their
time reading my code.
I had learned the project style, this was my original commit message, I don't see anything
particularly wrong with it, but it wasn't the style that they wanted, they wanted something
much shorter, they didn't want me to, they didn't want a long paragraph explaining, like
they felt like, I say they, Ian felt like add these functions was enough, I didn't need
a paragraph explanation, so I followed his style guide and ended up something shorter.
The tests, he wanted some changes in the test, I called t.fatal, but it was a for loop, so
if one test failed, the other test wouldn't run, so he wanted me to do t.error instead.
Cool, makes sense.
And then Godoc recently, I don't know how recently, recently in my mind because I used
it before this, but they recently added these square brackets to do hyperlinks and stuff,
and I didn't do that, so I needed to add that.
Yeah, little nitpicky things, plus I forgot to run the test.
That was kind of it.
That was my thing.
It got merged on March 27, so just over two years after the original, was that right?
Just under two years after the original issue was opened, it got merged, and then it was
in the Go 121, yay!
My name's not there.
It's in, it's in Git somewhere, but whatever.
It still felt good.
So I think I just breezed through that.
I have a lot of time here.
We have a time for questions here.
I mean, I have a few more slides, but this is the point of my talk, really.
What does it take to become a Go contributor, and what does it not take?
So non-requirements are you don't need mad hacker skills.
I mean, you saw the simplicity of that code I wrote.
Now I've written much more complicated code, at least I like to think so, but not at the
Go project.
I've spoken to people who contribute to Go just by adding those square braces to Go
doc.
That's cool.
That helps.
I mean, that's valuable, right?
It's not cheating.
That gives me hyperlinks when I go to the Go doc for that package.
I can click on a hyperlink now.
That's useful.
So if that's what you want to do to contribute to Go, that's all you need to do.
All you need to know is how to type square brackets.
You don't need to know about zombie Go routines and whatnot.
You don't need deep Go knowledge.
What do you need to be a Go contributor?
I think the main thing I learned from this process is that for me to be a Go contributor,
I need patience.
I mean, a lot of that wall clock time was me not doing anything.
If I had been trying and pushing the process forward, I probably could have truncated that
down to maybe three or four months.
But that's a long time to get 20 lines of code implemented, I think.
I mean, relative to what I do at my day job anyway, where I do that 15 times a day or
something.
So it takes patience.
But if you're willing to put in the time, you can become a Go contributor.
It takes a little humility, especially when it comes to learning a new project style.
I mean, I don't know if you've contributed to other open source projects before.
I have.
Each one has their own flavor, their own style.
You need to learn that.
You need to be willing to learn that and not, yeah, just put your ego on the side.
That's not the point.
It's just to do something useful according to the community's guidelines.
And to learn some new things.
Yeah, I think I'll breeze through this.
Those of you who raised your hand that you were intimidated earlier, any of you feel
less intimidated now?
One, two, three.
Okay, my talk was a success.
That was my goal.
If you're interested in learning other ways, one of my goals is to make Go less scary for
people.
That's part of the Cup of Go podcast idea where we talk about the weekly Go news.
It's part of my YouTube channel, Boldly Go, if you want to watch that.
If you have questions, reach out.
You can find me at boldlygo.tech.
That's my Go themed website.
You can find all my socials and contact details there.
Any questions?
I don't know.
Do we have, we can do questions, right?
We have enough time for questions.
We have time, so yeah.
I will hand you the microphone.
If you're too far away, you'll have to shout and he has to repeat.
Hi, thanks for your talk.
I want to do a Cup of Go listener.
Wonderful, thanks.
Shout out to the podcast.
My question is, are there other ways to become a Go contributor like, you know, good first
issues or stuff and get up?
Other ways, other than introducing a proposal?
Yes, definitely.
You can find one of the existing bug fixes or proposals.
So this was the first code I wrote that was implemented to Go.
I had participated in the sense of filing bug reports and stuff like that previously
that others then fixed.
And many that had been just like closed as invalid or something that happens too.
There's that humility part that comes in.
But yes, there are a lot of open issues.
There are some tagged as good first issues.
You can find typo fixes, typo, I actually have an open CL.
It's the Garrett terminology for a PR.
Open for a documentation fix in a package in the center library.
Things like that.
There's a lot of things you can do.
You don't need to file either a bug report or a feature request.
You can find one that's already there.
Hello, thank you for your talk.
Yeah.
I've tried several times during Octoberfest to do some contribution.
And the big part of it was to find an easy issue to begin with.
Do you have some tips for that?
Not really.
I mean, there is a, I believe there's a tag on GitHub on the issue tracker for like good
first issue or needs help.
I know there's a needs help.
You could look at that.
I think there's a good first issue, but I might be confused about the different project.
One thing that is understandable but frustrating to me about the Go project is it's not really
designed for newcomers.
That's one thing I hope to help change with this.
Help at least lower the mental barrier that you might have individually to doing this.
But I say it's understandable because they're trying to build a professional quality, high
quality language and standard library.
And that requires one set of skills and guardrails around the project.
Being open to all new contributors is a different one and requires very different types of open
source management.
So Go, I think, mostly intentionally has moved to that side of high barrier to entry for
reasonably good reasons.
But that is frustrating for this question.
How do you find something you can do to contribute?
I don't really have a great answer except look through the issue tracker and find something.
In front.
Become a Fotherm organizer, get fitness for free.
Yeah, hello.
So you had this requirement at the beginning and this sparked the problem and the solution
in the library.
But what did you do in the meanwhile?
Because this took three years, right?
So what did I do about this in the two years in this thing between issue, file, and I didn't
do anything, honestly.
The person using the library, I'm assuming they had their own work around.
I mean, so there are work arounds for this sort of thing.
Suppose that you want to, suppose this already exists.
Now you're using Go 122, but you want a different version of the regular expression to be presented.
You have the same problem, right?
So you probably would end up wrapping the regular expression, reg x dot reg x type and
put your own custom marshal on it, for example.
That's probably what they were doing.
I do that with time dot time or time dot duration fairly frequently depending on the application
needs.
So that's probably what I would do.
Are there any differences in the main Go code versus like the Go X modules?
Yeah, that's a good question.
I haven't contributed to the X stuff, so I don't have experience to go on from there.
I think it's pretty much the same process though.
I do think the requirements for inclusion in the X packages are lower.
So if you want to add, say something to X slices, you want to add, I don't know, change
color or something, you know, some ridiculous thing there.
There's lower barrier to entry to get in there because it's considered experimental.
So you're like, if you want to do it in the center library, they have a high standard.
Like we want to make sure that we're never going to regret doing this.
In the experimental they're like, yeah, we don't know if it's a good idea, but let's try it.
So in that sense it's easier, lower barrier to entry.
Any last questions?
Okay.
I think this can mean one thing, but it was an amazing talk with not too many questions
left.
Round of applause everyone.