For a long time we planned to send a patch to Go, but always postponed?
 
Faced with difficulties, did not know where to start?
 
In this article I will describe how we conducted the Go contribution workshop in Kazan,
 
about its results, as well as about the lessons that the organizers have learned.
 
Spoiler: It is planned to repeat this event when Go goes into the active development phase (exits the code freeze state). See the details under the cut.
GopherCon .
 
Someone comes to help others understand the work process, pick up the problem and solve it, then go through the review and, ideally, reach the infusion of the patch in upstream . Others come in as a "First Time Contributor".
 
If you are interested in one of the following, you might be interested in participating:
 
 
To be immersed in low-level details Go tulchejna (the compiler, the linker, the assembler, )
 
Speed ​​up some function from the standard library or run
 
Add missing examples or tests for any of the packages
 
Refactoring some very terrible code
 
Finalize support for a rarer architecture or OS (with you hardware and /or OS)
 
To communicate with those who already for a long time contribute in Go
 
 
The list is not complete, everyone can find something of their own in this.
 
Workshop in Russia
 
At some point, I decided that I wanted to put my hand to organizing such an event. Most of all I wanted to be in the circle of people with similar interests.
 
The preliminary program of the exercise was approximately 6-10 hours (the range of the best and worst case). The most suitable format was the hackathon, but it was not possible to find sponsors at that time. But it was possible to conduct elective classes for Scientific and practical platform IVMIT KFU , once a week for an hour and a half. The obvious drawback: due to large breaks between participation, it would take some extra time. And no pizza.
Sigh
 
Quite unexpectedly, I was a guest in podcast GolangShow (ep. 119) , where he talked about the idea of ​​doing something similar for students. A bit later Elena Grahovac created the channel # kfu-go-2018 in of the Russian community Go . There could communicate not only KFU students, but all those who were interested to participate remotely.
 

After that, the university approved the details of the meeting, certain dates became known. Instead of the hackathon, they received a course in the Go programming language. This did not change much of the content, the goal remained the same and it was clearly described in announcement .

Then came the scan tracker in the search for tasks that could be performed within the framework of the event, at least partially (even better - completely).

Any participant could go to the tracker Go and choose anything for himself, but for the tasks from the list explanations were ready, and for some of them a partial solution.

Most of the content that was generated during the course is available in the repository kfu-go-2018 . There you can find tasks.org .

The first meeting was

Students who had not previously written on Go came. Most of them have not even heard of such a programming language.

Half of the first lesson we spent on building Go from the sources. On different computers there were different, including unexpected problems. Different OS, versions of system compilers (someone did not intend to Go 1.4), and so on. It did not work tritely ./make.bash ( make.bat for Windows) with different errors.

When the majority still had a working Go, our first Hello World was the output in the compiler ( go tool compile ) Of the canonical message when a new flag was sent to it.

It took 90 minutes: talked about Go, compared it to C ++, collected the tulcein, disassembled the bootstrapping process and collected the updated compiler.

The first patches in the project Go

For the second lesson, the goal was to go directly to contributing:

•  
  
• Agreed with Daniel Martí that it will be available at the agreed time and will be able to hold a review (put +2 if the patch is trivial and correct).  
  
• Ilya Tokar suggested scratch repository, where it's much easier to send the first CL (change list). Allows you to try out gerrit in work without risks, something to break.  
  
• Prepared stickers for delivery to those who successfully poured patches in Go.  
  

We were lucky: the scratch repository was broken. Someone sent the incorrect code to the repository and because of this trybots (CI tests) always failed. One of the tasks that I prepared was to fix what was causing the build error.

By the end of the lesson 6 patches were sent:
 
CL105415 , CL105395 , CL105356 , CL105416 , CL105355 , CL105375 .

Stickers got everyone.

It took 180 minutes: disassemble the process of developing Go, all designed Google CLA , set up gerrit, sent "hello world" patches, fixed the scratch repository assembly, and one of the participants managed to send the patch to golang /go (merge was the same day).

The rest of the classes took place according to a more free scheme. We came and worked on our tasks, exchanged experience and helped each other. Almost every such meeting was sent several patches.

Then came the code freeze and the course approached the logical end. By this time it was poured 17 patches . We are still going on Saturdays and working on different Go utilities

Difficulties of the "second step"

The easiest way was to take the first step. For those who are unsure of working with git, the scratch repository is a great solution.

It was not too difficult to find problems of minimum volume and not requiring much context. Various linters helped here. Run " gometalinter --enable-all " On the package of GOROOT and choose what to correct.

It was more difficult with the tasks to the level above. It was difficult for me to suggest this, but it was difficult for them to choose this. At the same time, it was understood that we had already outgrown the correction of linter warnings (that is, the challenge was gone, for new productive tasks it was necessary to look for new types of tasks).

In theory, a good second-level task is to improve the tests in Go: increasing coverage, adding or improving benchmarks, fixing not completely correlated or disabled tests, testing regression tests, and so on. This requires some immersion in the tested package, but the scope of changes will be minimal and it is easy enough to check the result. But not everyone likes to work with tests.

Examples from what we managed to take as tasks of the second level:

1.  
   
2. encoding /json: add the full path to the field in UnmarshalTypeError ( # 22369 )  
   
3. time: optimize time.Time.Sub and time.Since ( # 17858 )  
   
4. cmd /compile: avoid slow versions of LEA instructions on x86 ( # 21735 )
    
    
   We started them closer to the code freeze, so we did not have time to finish it: there were 2 Saturdays for 90 minutes, but this is not enough. Moreover, everyone worked on their task. Perhaps it would be easier in the case of splitting into teams at least two people, for example, in the case of issue21735 , you can simultaneously test different hypotheses and study different parts of the compiler in parallel, then share knowledge.
    
   Lesson №4 [/b]
   Most of all, it is worth paying attention to this part, the inevitable deepening and the issues that follow. I doubt that there are people who know all parts of Go so as to be able to support with any choice, so here everything again converges to the shortage of different experts.
    
   Workshop v2
    
   Some of the problems described above would be solved by an alternative format, when a more complex task would not require solving it for three weeks. The next workshop should be held as a continuous event, at least for 4-5 hours, and ideally with a break and for longer.
    
   Usually the format of the hakaton also implies some preparation of the participants before the start, namely the choice of the task and the preliminary description of the ways of its solution, the formation of teams. This, too, can help increase the number of successful contributions.
    
   Need more mentors who can in real time help participants choose and solve problems.
    
   The choice of a city depends on the number of participants and their geographic distribution. I'm closer to four options: Moscow, Innopolis, Kazan, Nizhny Novgorod.
    
   In conclusion,
    
   It is not necessary to come to similar hackathons to start contributing to Go, a motivating example may be an article by Marco As a newcomer to Go, it was . However, in the company of the same interested people it is easier to overcome the initial discomfort and confusion, to go from the beginning to the end.
    
   If you are not indifferent to this topic, stay tuned for updates, look in at golang-ru.slack . The next period of active development of Go begins with August 2018 : not too far to forget about it, and not too close, so as not to have time to properly prepare.
    
   Bonus materials for beginner contributors
    
    
   Speech How to contribute in Go Stanislav Afanasyev ( Goandfix.me )
    
   Slides How to Contribute to Go
    
   Slides Golang compiler internals for ARM64
    
   Relatively recently, new readme began to appear, aimed at new contributors: cmd /compile , cmd /compile /internal /ssa .
    
   Only registered users can participate in the survey. Enter , you are welcome.
   Would you like to participate in the Go contribution workshop?
   Yes, in the form of a participant
   Yes, in the form of a mentor /reviser
   No
   No, but I support the idea
   2 people voted. There are no abstentions.