Apertium has moved from SourceForge to GitHub.
If you have any questions, please come and talk to us on #apertium on irc.freenode.net or contact the GitHub migration team.

Task ideas for Google Code-in

From Apertium
(Difference between revisions)
Jump to: navigation, search
(add stats-service tasks)
(Counts)
Line 369: Line 369:
 
== Counts ==
 
== Counts ==
   
Last updated by [[User:Sushain|Sushain]] ([[User talk:Sushain|talk]]) 02:16, 13 September 2018 (CEST).
+
Last updated by [[User:Sushain|Sushain]] ([[User talk:Sushain|talk]]) 03:07, 13 September 2018 (CEST).
   
 
{| class="sortable wikitable"
 
{| class="sortable wikitable"

Revision as of 02:07, 13 September 2018

Contents

This is the task ideas page for Google Code-in, here you can find ideas on interesting tasks that will improve your knowledge of Apertium and help you get into the world of open-source development.

The people column lists people who you should get in contact with to request further information. All tasks are 2 hours maximum estimated amount of time that would be spent on the task by an experienced developer, however:

  1. this is the time expected to take by an experienced developer, you may find that you spend more time on the task because of the learning curve.

Categories:

  • code: Tasks related to writing or refactoring code
  • documentation: Tasks related to creating/editing documents and helping others learn more
  • research: Tasks related to community management, outreach/marketting, or studying problems and recommending solutions
  • quality: Tasks related to testing and ensuring code is of high quality.
  • design: Tasks related to user experience research or user interface design and interaction

Clarification of "multiple task" types

  • multi = number of students who can do a given task
  • dup = number of times a student can do the same task

You can find descriptions of some of the mentors here.

Task ideas

typetitledescriptiontagsmentorsbgnr?multi?duplicates
research Join us on IRC Use an IRC client to log onto our IRC channel and stick around for four hours. irc * yes 150
code, design Make source browser headings sticky at bottom of window Make headings that are out of view (either below when at the top, or above when scrolled down) sticky on Apertium source browser, so that it's clear what other headings exist. There is a github issue for this. css, javascript, html, web sushain, JNW no
code, quality Increase test coverage of begiak, our IRC bot, by at least 10% There are many modules without any tests at all, unfortunately. See the associated GitHub issue for more details and discussion. python, bot sushain, JNW no 4 4
code Improve the .logs command of begiak, our IRC bot Currently, the .logs command just links to the root logs. Ideally, it would link to the channel specific logs, support a time being handed to it and have tests. See the associated GitHub issue for more details and discussion. python, bot sushain, JNW no
code Update the awikstats module of begiak, our IRC bot, for GitHub There are a couple steps remaining for this process, mostly small modifications to the existing code which are enumerated in the associated GitHub issue which also contains more context and discussion. python, bot sushain, JNW no
code Add GitHub issue creation functionality to begiak, our IRC bot Ideally, this would be added to an existing module. If that doesn't make sense, a new module is acceptable as well. The associated GitHub issue includes an example of the command's usage and reply. python, github, bot sushain, JNW no
code Support GitHub modules in apertium-get Unfortunately, the transition to GitHub from SVN made it so this script which is very handy for downloading an Apertium language/pair doesn't fetch the newest packages anymore. This also means that beta.apertium.org is out of date. See the associated GitHub issue issue for more details and discussion. bash, github sushain no
code, quality Add default CI configs to Apertium packages via Apertium-init Currently, some Apertium pairs/language modules use CI but it's very inconsistent and doesn't come by default. Apertium-init is the official way to bootstrap a new Apertium package so if it came with CI support by default, that would be great. See the associated GitHub issue issue for more details and discussion. ci, circleci, yaml sushain no
code, quality Add default CI configs to Apertium packages via Apertium-init Currently, some Apertium pairs/language modules use CI but it's very inconsistent and doesn't come by default. Apertium-init is the official way to bootstrap a new Apertium package so if it came with CI support by default, that would be great. See the associated GitHub issue issue for more details and discussion. ci, circleci, yaml sushain no
code, quality Increase Apertium-init test coverage Currently, we have a decent set of tests for the script but there are some more complex behaviors such as GitHub interaction that we don't test. This task requires making substantial improvements to the test coverage numbers. See the associated GitHub issue issue for more details and discussion. python, unittest sushain no
code Ignore .prob files in bilingual modules created by Apertium-init Apertium-init bootstraps Apertium packages and comes with a default gitignore. This gitignore could be improved by making it ignore *.prob files but only for pairs since they are meaningful for language modules. It would be extra cool if we had some tests for this functionality that weren't too contrived. See the associated GitHub issue issue for more details and discussion. python, git sushain no
code Set repository topic on repos created by Apertium-init Apertium-init bootstraps Apertium packages and supports creating an associated GitHub repository. Our source browser and other scripts expect a GitHub repository topic like "apertium-incubator". This task requires creating the incubator topic by default on repo push with an option for custom topics. See the associated GitHub issue issue for more details and discussion. python, github, http sushain no
code Install Apertium and verify that it works See Installation for instructions and if you encounter any issues along the way, document them and/or improve the Wiki! bash ftyers, JNW yes 150
research Write a contrastive grammar Document 6 differences between two (preferably related) languages and where they would need to be addressed in the Apertium pipeline (morph analysis, transfer, etc). Use a grammar book/resource for inspiration. Each difference should have no fewer than 3 examples. Put your work on the Apertium wiki under Language1_and_Language2/Contrastive_grammar. See Farsi_and_English/Pending_tests for an example of a contrastive grammar that a previous GCI student made. wiki, languages Mikel yes 40
quality Add 200 new entries to a bidix to language pair %AAA%-%BBB% Our translation systems require large lexicons so as to provide production-quality coverage of any input data. This task requires the student to add 200 new words to a bidirectional dictionary. xml, dictionaries, svn Mikel yes yes
quality Disambiguate 500 tokens of text in %AAA% Run some text through a morphological analyser and disambiguate the output. Contact the mentor beforehand to approve the choice of language and text. disambiguation, svn Mikel yes
code Use SWIG or equivalent to add C++ bindings for text analysis in apertium-python Currently, apertium-python just pipes text through the binaries in each mode file. We would like to directly execute the associated C++ function instead. See the associated GitHub issue for more details and discussion. python, c++, swig sushain no
code Integrate HFST's C++ Python bindings into apertium-python Currently, apertium-python just pipes text through the binaries in each mode file. Where appropriate, i.e. a mode accesses HFST binaries, we would like to directly execute the associated C++ function instead. python, c++, swig sushain no
code Improve the apertium-python Windows installation process Currently, apertium-python requires a complex installation process for Windows (and Linux). The goal is something that works out-of-the-box with pip. See the associated GitHub issue for more details and discussion. python, windows sushain no
documentation, code Setup documentation generation for apertium-python Currently, there are some docstrings attached to functions and constants. This task requires setting up Sphinx/readthedocs for apertium-python so these docs are easily accessible. Types should also be visible and documentation should support being written in Markdown, not RST. See the associated GitHub issue for more details and discussion. python, sphinx sushain no
code, design Upgrade apertium.org (html-tools) to Bootstrap 4 Currently, we are on a frankensteined version of Bootstrap 3. See the associated GitHub issue for more details and discussion. Note that the frankenstein'd CSS will likely need to be fixed and theme support should be retained (should be simple). javascript, css, web, bootstrap sushain no
code, quality Get apertium.org (html-tools) QUnit testing coverage working Currently, we have a QUnit testing framework mostly complete. There are some fixes that need to be made in discussion with the mentor and existing comments and JS coverage checking needs to be added so that we can burn down existing debt. See the associated GitHub PR for more details and discussion. javascript, jquery, web sushain no
code, quality Fix/prevent apertium.org (html-tools)'s recursive website translation Currently, if you try translating Apertium's website with Apertium's website, bad things happen. This 'exploit' is also possible through mutual recursion with another site that offers similar behavior. See the associated GitHub issue for more details and discussion. javascript, jquery, web, bootstrap sushain no
code Convert apertium.org's API (APy)'s language name storage from SQL to TSV Currently, language names that power part of the Apertium HTTP API are stored and updated in SQL. It would be nice if they were stored in a more human readable format like TSV and the SQLite were generated at build time. See the associated GitHub issue for more details and discussion. python, sql, tsv sushain no
code Support unicode without escape sequences in apertium.org's API (APy) Currently, HTTP responses with unicode characters are emitted as \uNNNN by the Apertium API. Ideally, the character could just be decoded. See the associated GitHub issue for more details and discussion. python, api, unicode, json, api, http sushain no
code Make apertium.org (html-tools) fail more gracefully when the API is down Currently, html-tools relies on an API endpoint to translate documents, files, etc. However, when this API is down the interface also breaks! This task requires fixing this breakage. See the associated GitHub issue for more details and discussion. javascript, html, css, web sushain no
code, design Refine the apertium.org (html-tools) dictionary interface Significant progress has been made towards providing a dictionary-style interface within html-tools. This task requires refining the existing PR by de-conflicting it with master and resolving the interface concerns discussed here. See the associated GitHub issue for more details and discussion. javascript, html, css, web sushain no
code, documentation Add a Swagger/OpenAPI specification for apertium.org's API (APy) There's been some work towards this already but it's outdated. This task requires updating it and for bonus points ensuring at build time that all paths are minimally present in the Swagger spec. Furthermore, it would be awesome if a simple HTTP page could be made that loads the spec (e.g. this page for another service). See the associated GitHub issue for more details and discussion. python, api, http, openapi, swagger sushain no
code Accept ISO-639-1 codes in apertium-stats-service This task requires making /en-es, /en-spa, etc. work the same as /eng-spa and then adding tests that verify the behavior. See the associated GitHub issue for more details and discussion. rust, api, http sushain no
code Accept ISO-639-1 codes in apertium-stats-service This task requires making /en-es, /en-spa, etc. work the same as /eng-spa. See the associated GitHub issue for more details and discussion. rust, api, http, rest sushain no
code Support listing of packages in apertium-stats-service This information is something that is useful in a lot of different places, for example, our source browser. By having the stats service implement it, everyone doesn't have to write the same code in different languages and the information gets cached. For GCI task credit, the last commit info is not required (another task can be made for that feature). This task requires implementing the initial feature, adding some basic tests and tweaking the swagger spec. One or more of those tasks can be broken into other task(s) if the mentor sees fit and the student requests it. See the associated GitHub issue for more details and discussion. rust, api, http, rest sushain no
code Add configurable timeout support to apertium-stats-service Currently, a stats request has no clear timeout and can take ~forever if the async option is not present. This tasks requires adding a timeout option, adding tests and then tweaking the swagger spec. See the associated GitHub issue for more details and discussion. rust, api, http, rest sushain no
code Surface errors to the client in apertium-stats-service Right now, errors are logged and swallowed. The client never knows what happened. This task requires implementing the feature, adding some basic tests and tweaking the swagger spec. One or more of those tasks can be broken into other task(s) if the mentor sees fit and the student requests it. See the associated GitHub issue for more details and discussion. rust, api, http, rest sushain no
code Include Git SHA in apertium-stats-service's file info Right now, only the SVN revision number is provided but that doesn't help with mapping back on to a SHA in Git/GH for the client. This task requires implementing the feature, adding some basic tests and tweaking the swagger spec. See the associated GitHub issue for more details and discussion. rust, api, http, rest, git, svn sushain no

Counts

Last updated by Sushain (talk) 03:07, 13 September 2018 (CEST).

Category Count
code 30
documentation 2
research 2
quality 8
design 3
Total 37
Personal tools