Google Code-In (GCI) is happening again this year. The Ubuntu project participated in 2015. I wanted to float the idea of Ubuntu participation in this year’s GCI.

For those that don’t know GCI is a program run by Google to introduce 13-17 year olds to open source development. Participating organisations come up with a long list of tasks to be performed by students from around the world. Each task is expected to be up to a few hours in duration and they can vary in difficulty level.

There are a set of categories in which the tasks are grouped:

Coding

Documentation / Training

Outreach / Research

Quality Assurance

User Interface

These aren’t limited to Ubuntu desktop though. We could include flavour specific tasks, general archive opportunities, and server / cloud or IoT / Snap related activities. Our documentation could certainly do with a few fresh eyeballs, especially with all the desktop changes this cycle. In addition, with our new GNOME desktop default, now would be a great opportunity to encourage new open source contributors to help with upstream tasks too.

We would need a diverse set of mentors from around the various projects involved in the GCI application.

The application process starts on Monday 9th October, and we have two weeks to get our application in. The accepted participating organisations are annouced on Thursday 26th October. GCI starts for the students on Tuesday November 28th and runs until the deadline for claiming new tasks on Monday 15th January, and all work needs to be submitted by Wednesday January 17th.

We must complete the evaluation of the student’s work by January 18th whereupon the winners are annouced at the end of January.

So, we have a weekend to discuss and decide if we’re going to apply, a couple of weeks to come up with a ton of tasks, and then a couple of months worth of mentoring students and maintaining a pipeline of tasks.

Find volunteers within the community who have a few hours a week to spend on mentoring

Identify admins who can act as fallback for the mentors

Start work on a list of sample tasks for the students

If we go for it then we need to: (before Monday 23rd October)

Build a corpus of diverse tasks for the students, covering all the groups, at each level

Create the application

If we get accepted we need to then:

Ensure we don’t run out of tasks for the students

Have the mentors respond to the students in a timely manner

I’d love for us to get involved, but it’s a lot of work, and we’d need commitment from everyone to work as per the guidelines above (and on the GCI site) for the full duration of GCI. I’ve already spoken to a few people in Canonical who would love to get involved. This is a lot to do, especially with the Christmas holidays in the middle, and an Ubuntu release right around the corner.

However, I think this could be a great opportunity to help build the next generation of open source contributors. I welcome everyone’s input on this. Especially people who wish to volunteer as mentors and can help get tasks created and maintained.

Get the final touches put on modernizing the Ubuntu Packaging Guide, and release 1.0 (there’s some pretty easy tasks involved, I just have less time lately.

Lubuntu Next needs some final touches, and I’d like students to help test and write new features.

As with in 2015, let’s get people to test specific applications within Ubuntu and flavors and report back to make sure the packages are working properly. Also have them perform ISO QA tasks.

Kubuntu could use some help with organization of the Kubuntu Automation tooling, and unit tests should really be written for those but nobody has stepped up yet within the team to do it (I would but again, time… ).

Some of the Ubuntu Weekly Newsletter tooling needs some fixing up and modernization (iirc it’s still on Python 2) because there’s some cases (like with two week issues) where I need to manually fix some of the files it’s generated. Having something be autogenerated to go on this site might be a task too…

That’s just what I can think of off the top of my head.

One thing I am wondering though is since Snappy is a Canonical project and not (from what I can see) an official “Ubuntu” project per say (but rather a Canonical one), if it should have a spot in GCI if Ubuntu gets accepted.
(I would compare it to if Juju or MaaS wanted to be in GCI as an Ubuntu subproject, the project leadership seems to only be Canonical employees and not open to the public (which is how I personally classify whether a project is Canonical-only or Ubuntu-as-in-Community), at least in my perception)

One thing I am wondering though is since Snappy is a Canonical project and not (from what I can see) an official “Ubuntu” project per say (but rather a Canonical one), if it should have a spot in GCI if Ubuntu gets accepted.

Ubuntu desktop and server has the capability to consume snaps out of the box for over a year. So yes, snaps are totally within the remit. In addition, Snapcraft is in the Ubuntu archive, and is used to create packages which Ubuntu consumes. While they’re both separate projects, there’s plenty of scope for doing things which affect Ubuntu users directly.

We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence.

So I suppose it depends on exactly which projects fall under the scope of the Ubuntu Code of Conduct.

However, I might be off for the whole month of December, but I heard that other people in the desktop team may be interested by this. I can still help preparing and bootstrapping the first set of students + final review.

Ubuntu desktop and server has the capability to consume snaps out of the box for over a year. So yes, snaps are totally within the remit. In addition, Snapcraft is in the Ubuntu archive, and is used to create packages which Ubuntu consumes. While they’re both separate projects, there’s plenty of scope for doing things which affect Ubuntu users directly.

But the same exact thing can be said about Flatpak right?

Just because it’s installed by default doesn’t make it an Ubuntu project.

rbasak:

So I suppose it depends on exactly which projects fall under the scope of the Ubuntu Code of Conduct.

Do Snappy-related projects follow this specific clause? I would be curious to get an answer from someone over there.

Given how many people get involved in GCI, and how many tasks they can potentially burn through, I certainly don’t think we should be looking for things to exclude from the remit! Having people like yourself and @rbasak with detailed debian packaging skills, and people like @elopio with detailed snap skills, will benefit the project and participants.

I don’t think many people within the Ubuntu project have much in the way of flatpak skills. If there are people who want to step up and mentor that, then I’m certainly not going to say no if it benefits the projects.

Given how many people get involved in GCI, and how many tasks they can potentially burn through, I certainly don’t think we should be looking for things to exclude from the remit! Having people like yourself and @rbasak with detailed debian packaging skills, and people like @elopio with detailed snap skills, will benefit the project and participants.

I don’t think many people within the Ubuntu project have much in the way of flatpak skills. If there are people who want to step up and mentor that, then I’m certainly not going to say no if it benefits the projects.

Ok, that’s fair, and it’s all good with me as long as the Snappy-related tasks directly benefit Ubuntu, whether it be Desktop, Server, flavors, or anything else we ship. Where I don’t (personally) think it fits is just adding random (even if useful) features to Snapcraft, for example.

I understand and respectfully disagree with you, but that’s fine. You don’t have to mentor the people who are doing snap and snapcraft related tasks, other people can take that workload on. You can focus on the things that matter to you.