Google Summer of Code 2020

[bovine3dom]

Pros:

• get a student to work on Tridactyl (and a few pennies) over the summer

• kudos of being part of GSoC

• "ideas list" that can be used for any contributors to Tridactyl, new and old, to sink their teeth into.

Deadline for applications is 7pm London time, 5th Feb 2020.

Useful links:

https://summerofcode.withgoogle.com/how-it-works/#timeline

https://google.github.io/gsocguides/mentor/org-application

https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Todo:

• Ask who would be willing to mentor students (ideally at least two, i.e. one non-bovine3dom entity)

• Come up with project ideas

[glacambre]

A few ideas:

• Chrome port.
• A testsuite that is actually good.
• Remove all of the compile time stuff we have (TypeDoc, the excmds script, the custom compiler pass).
• Keyboard API.

I would be willing to help mentor students on the first three projects. I probably won't have enough time/knowledge to feel comfortable mentoring somebody working on the keyboard API.

[bovine3dom]

• "gamepadactyl" could be a cool one as a fun project. After getting detection, hinting and text input to work well (I really like Steam's 360 flower keyboard) with a decent theme it could actually turn Tridactyl into a good way of browsing the net on a big screen.

• "vimium-style" smooth-scroll where pressing and holding j immediately puts you in smooth scroll 'mode' rather than our current behaviour of "scroll a bit, and then keep scrolling as j is fired again". (Related: keyup/keydown binds)

• TreeStyleTab integration / integration with other extensions

• Find mode improvements, e.g. completions

• Integrating @ELLIOTTCABLE's parser (?)

• Ability to disable Tridactyl totally on a page

• Working out how to safely update Tridactyl while Firefox is running (probably related to totally disabling Tridactyl)

• Lazy injection of iframe

• Tab history list (i.e. completions but for history of current tab)

• Frame support

• Performance improvements / adding performance testing to tests

  • especially Windows

• working out how to get users off 1.15.x

• Tridactyl website with a live demo / more interactive tutorial (e.g. like Oni's).

I think the "remove all the compile time stuff" could be summed up as "make our build/release process less mad + faster" (scripts/sign alone is pretty awful).

In the next week or so we should whittle these down to our top 5 or so and flesh them out.

[ELLIOTTCABLE]

I'd be plenty happy to mentor anybody on parser nonsense, of course. (=

I'd also been planning to do the TST integration myself "someday"; I don't really know if I should offer to 'mentor' that, though, because it's not like I've used TST's API before ... hrm.

[saulrh]

From the student's perspective, I think the most attractive options are:

• Keyboard API, since that'll introduce the student to Real Open Source Software (rather than our tiny little thing), API design, bureaucracy, real release engineering, and all the other real-world tasks that even a project like Tridactyl rarely has to deal with.
• Finalize, integrate, and switch to the new parser. This is an excellent but not overwhelming introduction to some of the real-world problems that crop up in human-computer-interaction. I've seen a lot of students (including myself!) know their theory forward and backward but totally failed to actually use it when the time came because their classes presented spherical-cow-in-a-vacuum formal models.
• Chrome port. This would be a good exercise in portability, build systems, and multi-platform testing. Doing the necessary refactoring to insert the compatibility layer would be a good software engineering task all by itself.

[saulrh]

I think that we'll actually want a Tridactyl-in-a-page demo as part of our application's landing page. That's an eye-opener. We'd have until Feb 20 to get that up and running.

A tip from writing grant proposals, if people aren't familiar with how to make this kind of thing happen: Almost every request for proposals (which is what this is) has a list of objectives or goals or critical points somewhere. For several reasons, ranging from the phrasing of the instructions given to the proposal review committees to the paperwork they have to fill out to the improvement in writing you gain by following clear points, the advice I always got was to address these points directly, if at all possible by literally quoting the point in the proposal. For example, from the "what's on your application?" page: "How will you get your students involved in your community during GSoC?". We'll want to say, in as many words, that our plan for involving students in our community during GSoC is .

[saulrh]

On a related note, we should track down a "mission statement" for GSoC and use that to guide our ideas writeups. If the mission statement says that the goal of GSoC is to, for example, get students involved in real-world problems rather than theoretical exercises, each idea should literally say, in as many words, that it presents students with the real-world problems of X, Y, and Z.

[bovine3dom]

I've drafted up an ideas page - http://tridactyl.xyz/ideas/ - feedback strongly desired.

Edit it here if you fancy. https://github.com/tridactyl/site/blob/master/content/ideas.md

I think it really needs a table of contents - which Hugo does support https://gohugo.io/content-management/toc/ - but I haven't yet had time to wrap my head around how to get it working with our current theme.

Ta for input on application saulrh. I'll add a GSoC application page somewhere so we can draft our answers together.

[bovine3dom]

Draft application added here - https://github.com/tridactyl/site/pull/1/files?short_path=e9ec17c#diff-0

Most fields have 1000 characters permitted and we're using about 400 on most of them, so we have lots of room to expand. Feedback/contributions strongly desired : )

[bovine3dom]

@saulrh, from https://google.github.io/gsocguides/mentor/index#goals-of-the-program the goals are:

Goals of the Program

The program has several goals:

• Get more open source code written and released for the benefit of all.
• Inspire young developers to begin participating in open source development.
• Help open source projects identify and bring in new developers.
• Provide students the opportunity to do work related to their academic pursuits during the summer: “flip bits, not burgers.”
• Give students more exposure to real-world software development (for example, distributed development and version control, software licensing issues, and mailing list etiquette).

[bovine3dom]

(We weren't accepted this year - apparently I forgot to update this issue)