Project Ideas
Please see also https://github.com/coala-analyzer/coala/wiki/Writing-a-Thesis-with-coala if you're interested in scientific work. Students are expected to work out a full project proposal in cooperation with us, especially the mentor. Any application without prior contribution to coala cannot be evaluated and will be rejected. We will help you aiming your proposal to reasonable goals but we won't proofread it. (You can ask fellow students to do that.)
http://coala.readthedocs.org/en/latest/Getting_Involved/Newcomers.html will help you getting started with coala.
Note: We have a lot of interested applicants this year and we would recommend that new applicants apply to other organizations if given the opportunity.
You can contact all mentors and admins on our Gitter coala GSoC channel https://gitter.im/coala-analyzer/coala/gsoc.
The following people are potential primary mentors:
The following people are secondary (co) mentors:
If you have particular questions or problems with a mentor (or an admin), feel free to approach our GSoC administrators @Makman2, @sils1297 or @fneu privately on Gitter so we can help you resolving it. If you have problems contacting your mentors, contact us ASAP.
See also: An example project from a student in GSoC 2014 (a GNOME+coala project) - link
Please design your project in a way that you have multiple checkpoints. We'd like you to specify at least three partial goals so if something goes wrong for a valid reason, we can rearrange your schedule meaningfully. Each of those goals has to be merged into the main coala codebase in order for it to be considered "complete". You should be aware of what that involves for you (writing tests, going through extensive code review, learning :), reiterating).
You can use any project idea listed here or one that came out of your mind - however be sure to make us aware of your plans and start planning your project with us so we can coordinate and - in the worst case - prohibit waste of time from your side. At all cost make sure you find something that interests you. We want this to be a fun and educating experience for you!
Use the "draft" feature on the GSoC system, submit your draft early, get a lot of helpful feedback from us!
Please follow the proposal template at PSF-ApplicationTemplate2016. All fields are required if not explicitly indicated otherwise. While following the application template you can consider doing an illustration of your proposed solution as it makes the application much more intuitive.
In the code sample section: Please list links to your contributions to coala or any other OpenSource project. Your contributions may or may not be available on github or related to coala!
For example, to list your contributions to coala you can mention:
- https://github.com/coala-analyzer/coala/commits/master?author=YOUR_USER_NAME for coala repo
- https://github.com/coala-analyzer/coala-bears/commits/master?author=YOUR_USER_NAME for coala-bears repo You may also mention specific issues/commits using the commit id if you want us to take a look at that.
In the extra information section: We'd like the following sub-org specific info for coala:
- Will you be able to join us for a conference such as EuroPython or GUADEC and present your work if at least partial sponsorship will be provided? (See https://github.com/coala-analyzer/coala/wiki/Conferences-Upcoming)
- We love having twitter handles so we can tell people publicly about your great project and successes at https://twitter.com/coala_analyzer! (Not required but recommended.)
If needed, you can get further information about GSoC at http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code/.
There are a few things you should be aware of:
- In order to pass the evaluations we require your contributions to be reviewed and merged. Your mentor should ordinarily review your work within 24 hours, but be prepared for lots of constructive feedback.
- You should be already aware that we require full test coverage for your code to be accepted.
- We require you to do a blog post at least every two weeks, it will be aggregated on http://planet.coala-analyzer.org/.
- Your mentor will do a weekly meeting with you to make sure none of your questions remain unasked. :)
- Sooner or later you will be (or have already been) asked to review PRs of other students and newcomers. Code review is not an activity for some privileged members of the community but an important experience that should be part of your GSoC! Of course especially in the beginning we'll be there to guide you to that so don't worry!
Possible mentor(s): @sils1297
We want the bears to be able to submit multiple possible patches for one problem and patch generators for one problem. In the end, users should be able to choose between different patches (e.g. for different possible spelling corrections) and perform e.g. variable renamings (coala asks them for the new name and the generated function provided by the bear will generate a patch from that).
That needs some concept (to be worked out for the proposal together with us before application submission), implementation in the core infrastructure (the main part) and adaption of editor plugins (if needed) and the CLI.
Difficulty: Hard
Requirements: Talk to us about your proposal! The concept needs to be solid.
Related issue(s): https://github.com/coala-analyzer/coala/issues/1021
Possible mentor(s): @fneu, @Udayan12167
Jenkins has some neat way to show code analysis results - let's use that to provide Jenkins users an awesome usability! The result of this project should be a full fledged Jenkins integration, living in an own repository with a full testsuite.
If you find this fun you'll be the one knowing this component best and will get the chance to maintain it on your own if you want - always with the support of the community guarding your back of course.
Difficulty: Medium
Requirements: Interaction with the Jenkins community and the submission of a patch to Jenkins would be preferred.
Possible mentor(s): @Makman2, @Udayan12167
In the future we want coala to guess several things automatically to provide a neat out of the box analysis functionality:
- Languages used
- Certain settings, like indentation; tabs/spaces; ... (per language)
coala could thus run a number of specified bears on the code files with different but sensible configurations and compare the number of raised results, automatically choosing the configuration that yields the lowest number of results.
Difficulty: Medium
Possible mentor(s): @sils1297, @Udayan12167, co mentor @AbdealiJK
coala's results already have a severity, but this is not really the same as the confidence, which expresses how likely it is that a result - severe or not - might be a false positive. This project is about adding a confidence to the Result object and setting it correctly for a number of bears. It should also involve integrating the confidence into the CLI, CI, JSON output as well as some plugins.
Difficulty: Easy
Possible mentor(s): @AbdealiJK, @sils1297
Currently coala holds all 50+ bears in one repository. This results in a lot of dependencies for the coala project - you have to install all 50+ bears when you need only 1. You can either get all bears or none of them. The goals of this project are:
Move out each bear in an own PyPI package
This involves writing a script which can possible generate a setup.py file. The setup.py file can then be used by twine to deploy the package to pip like how the coala-bears package is currently deployed. This would involve handling metadata and packages that need to be bundled.
Setting up continuous integration and release automation
We need to test the bears properly. In this new structure we want the CI to work and this would involve a bit of configuring. The current coala-bears CI has been set up and runs for most bears in appveyor, travis and runs for all bears in circleci. Other than configuring getting more bears to run on travis and appveyor would be great.
We do not want to create 50+ development releases every time a PR gets merged into master (with rultor). So, we need some sort of method to check which files have changed in a PR and only deploy the bears which have been affected.
Handle dependencies using some dependency management tool.
We also want bears to be install-able using pypi and hence pip. Hence, it would be a good idea to make a new library which allows setuptools to install packages from npm, goop, gems, etc. This can be done by simply calling the package manager using subprocess. Hence this will be a very thin wrapper over the current package managers.
Difficulty: Medium
Possible mentor(s): @sils1297, @Makman2
Recently, coala switched from a home grown testing framwork to PyTest. This allows us to run documentation as tests to complement our testsuite. This improves the API documentation while giving meaning to some of the tests. This project includes:
- Proper installation of a manpage.
- Moving various tests as useful examples to documentation comments.
- Removing redundant tests.
- Various related test suite refactorings.
- Work on the coala testing infrastructure, especially the LocalBearTestHelper class and other test generation utilities.
Difficulty: Easy
Possible mentor(s): @sils1297, @fneu
The aim of the project here is to enforce coala on devs. i.e. not to let them push unless coala says the code has no issues.
This allows to run coala over a commit or the current changes. git is important and widely used, and ideally support for hg and others may be added later. Take inspiration from git-lint. A prototype of a coala script that runs incrementally over git commits is available at https://gitlab.com/gitmate/coala-incremental/.
git hook
We already have a bit of documentation on using coala as a pre-commit hook - http://coala.readthedocs.org/en/latest/Users/Git_Hooks.html
using this we can run coala before a push, but it's not ideal and is too slow.
Cache system
coala curretnly doesn't cache results. We have a tagging system to tag results and then no show the same result the next time (This is what coala-incremental does). But the analysis still takes a fair bit of time on large projects. We don't want users to wait for a minute when they do a git push. Hence, we should cache the files that coala has already run and have some method of finding which files have changed since the last time. If a file has not changed, LocalBears need not run on that. Global bears would still need to be run.
The cache system should be independent of git/vcs. On running coala the first time, it may take 30 sec, but if nothing has changed, the second time should take <1sec as the results will be cached already.
Cache in git hooks
Once the above cache system, we can get the modified files from git and run coala only on these files. This would make it fast. Also, we need to somehow identify all the new commits added to this branch and run coala on all of them (if the user wants to, using some config?). And only allow the push if coala passes on all of the new commits. This would allow users to have a local gitmate :)
Difficulty: Easy
Possible mentor(s): @Makman2, @Udayan12167
This project features the implementation of the decorator based bear design to make creation of algorithms even easier. (https://github.com/coala-analyzer/coala/issues/933) This includes the simplification of core parts of coala.
A technical prototype of the next generation bear design is available at https://github.com/coala-analyzer/next-gen-bears-prototype.
Difficulty: Hard
Requirements: Any student approved for this project will have to work closely together with us. It is required to at least fix a medium difficulty bug for the application to be accepted.
Bonus: The new bear design has a 110$ bounty that will be paid if the student completes the project in addition to any support from Google.
Related issue(s): https://github.com/coala-analyzer/coala/issues/933
Possible mentor(s): @sils1297, @AbdealiJK, @Makman2
A very easy way to cover a broad spectrum of analysis routines is wrapping linters into coala. Currently we have a Lint class which simplifies this integration. Based on this class, a large selection of linters can be implemented rapidly. A tutorial on writing linter bears is available at http://coala.readthedocs.org/en/latest/Users/Tutorials/Linter_Bears.html.
This project proposal should contain a concrete list of linters that are wrapped together with concrete improvement proposals to the Lint class if needed. Because implementing a linter bear is a rather trivial task it is highly recommended to spice up the project with something interesting, like adding automatic dependency installation to the Lint class. Improving integrations by adding more options can also be part of this.
Upstream contributions to linters are encouranged, e.g. to add auto fixing abilities.
Difficulty: Easy
Possible mentor(s): @sils1297, @Makman2, @Udayan12167
If someone writes a bear he/she needs to test it and comes likely to the step where debugging is needed.
In this project the participant shall develop a system to easily step into the analysis code (likely
using the Pdb module already integrated into Python) and step out as soon as the analysis finished.
On this way it would be useful retrieving profiling information while debugging/running.
Difficulty: Medium
Requirements: Familiarity with pdb is a plus.
Related issue(s): https://github.com/coala-analyzer/coala/issues/565, https://github.com/coala-analyzer/coala/issues/1101
Possible mentor(s): @Makman2, @sils1297
The goal of this project is to create and implement an algorithm that is configurable to various algorithms that figures out the right indentation for as many programming languages as possible.
The algorithm must at least handle:
- Keywords (function declaration, if statements, ...)
- Hanging indent (various brackets, comments, ...)
- Automatic line breaking (too long strings, seperating expressions, surrounding expressions in brackets, ...)
It should use language definitions which coala already has.
Basic versions that simplify this task contain the MatlabIndentationBear (which is fairly simple and Matlab/Octave specific but shows a feasible approach that can be extended) and the SpaceConsistencyBear (that shows how easy we make tab/spaces handling for you). The PEP8Bear/autoflake/flake is an example how a more sophisticated algorithm specific to a programming language might work.
This project might be combinable with a thesis or research work or lead to one.
Difficulty: Hard
Related issue(s): https://github.com/coala-analyzer/coala-bears/issues/40
Possible mentor(s): @Makman2, @Udayan12167
Documentation is an important part in software and ensures everyone can understand and directly use your code.
This project would deal with language-independent analyze routines that checks for a specific documentation format-style the code-writer shall follow. The routines shall also deliver (if possible) a patch that automatically formats the documentation correctly.
coala already contains facilities for extracting documentations out of code. What needs to be done next is:
- Language-independent documentation comment parsing. Summary and detailed descriptions, parameters and others shall be extracted so specific attributes can be easily analyzed.
- Write the analyze routine (the
DocumentationFormatBear). It will be put inside a bear so one can directly start using it.
This project can be extended to other documentation related stuff, like grammar checking etc.
Difficulty: Hard
Related issue(s): https://github.com/coala-analyzer/coala-bears/issues/34
Possible mentor(s): @Makman2, @rubdos, @Udayan12167
Currently bears (our analysis routines) can only be written in Python. For performance reasons it would be worth allowing to write them C or even other languages, so everyone that is familiar with his/her language he/she doesn't need to switch to Python.
This project allows you to write such a bear-frontend for a language of your choice.
Difficulty: Medium
Related issue(s): https://github.com/coala-analyzer/coala/issues/485
Possible mentor(s): @AbdealiJK, @sils1297 (co mentored by Christian Hergert from GNOME)
coala has plugins for gedit, sublime and atom. We'd like to extend this selection. One important thing is the GNOME builder integration that has to be and can be done properly (with settings via some UI, there's an API for that.) This project might be done in cooperation with GNOME and result in a better plugin API for GNOME Builder in which case it will be co mentored by the creator of Builder.
Difficulty: Medium
Requirements: You should sync up with Christian Hergert from GNOME and submit a patch to GNOME Builder.
Possible mentor(s): @AbdealiJK, @sils1297
coala has plugins for gedit, sublime and atom. We'd like to extend this selection. One important thing is the Kate and KDevelop integration that has to be and can be done properly (with settings via some UI). This project might be done in cooperation with KDE. It's majorly meant for developers who currently use KDevelop and KDE based editors to get the capabilities of coala easily!
Difficulty: Medium
Requirements: You should definitely sync up with the KDE people and submit a patch!
Possible mentor(s): @AbdealiJK, @sils1297
This project would need to implement plugins for Eclipse. Eclipse has a really nice method of using plugins for all sorts of things including code analysis. What we want to do is make a plugin which can integrate into Eclipse easily and run coala on a project or a specific file. We'd want to show warnings and errors in the Eclipse interface for easier use.
What we're looking for is a view that can show old results inside the editor easily. And a build step for coala which runs coala on the whole project. The user should also be able to enable static code analysis for on the fly issues if the user wants (Some bears are extremely fast). The next step when that is done would be to make an easy interface for coafile editing inside Eclipse so that the user doesn't need to go out of Eclipse for anything related to coala.
Difficulty: Medium
Languages: Java, Python
Possible mentor(s): @AbdealiJK, @sils1297
This project would need to implement several plugins for several editors. Ideally that list should include vim, emacs, IntelliJ/PyCharm, Notepad++, and many more. Part of this project would be coming up with an efficient strategy to make sure all plugins are tested and maintained properly.
Supporting the plugin
We consider any bit of code "supported" only if we have regular Continuous Integration and tests running to ensure it works. What this involves for this project is to setup tests for the current editor plugins. And then to configure the CI to run these tests once in a few days using the newest coala version. For some editors like sublime and gedit, running tests is not easy and there is no api to do it. In such cases we would want to use dogtail (a GUI tester) or similar to do this.
Documentation
We need better documentation on how to write a plugin and setup the CI for it. We could take 23 plugins and write details instructions on how they were made.
Making plugins
Developers are lazy. Hence, we need to be able to provide coala to them right inside editors and IDEs. This could involve any from the huge list of editors at https://en.wikipedia.org/wiki/List_of_text_editors or any that you personally like :)
Difficulty: Medium
Possible mentor(s): @AbdealiJK, @sils1297
This project involved design skills and front-end programming knowledge. It involves creating a website for coala. First phase would involve ideating on a good design. Once the design is set we would decide on which frameworks to use and implement the design. We have a brainstormed overview of the website and it's structure available at https://etherpad.gnome.org/p/coala-website.
Languages: Core frontend languages - HTML, CSS, JS (Maybe coffeescript, Angular and Less also - but we're flexible about this.)
Difficulty: Medium
Related issue(s): https://github.com/coala-analyzer/website/issues
Possible mentor(s): @AbdealiJK, @sils1297
We currently have a lot of good methods to show results with coala-dbus, coala-ci, coala-json and coala-format. We now want an interactive html webpage which can show all of coala's results.
A prototype of such a static website is available at http://coala-analyzer.github.io/coala-html/.
Difficulty: Easy
Related issue(s): https://github.com/coala-analyzer/coala-html/issues
Possible mentor(s): @AbdealiJK, @sils1297
We currently have a lot of good methods to show results with coala. One really nice method is to actually run it inside a browser. A lot of bears cannot do this, but about 10-15 of the bears which are pure python or JS projects can be run inside browsers easily. This project invoved refactoring coala and brython appropriately to get the demo inside a browser working.
Difficulty: Medium
Related issue(s): https://github.com/coala-analyzer/website/issues/20
Possible mentor(s): @Udayan12167, @Makman12167
We currently have a very non functioning gui implementation that only helps in editing the .coafiles. We now want a good results view. The placeholders for that is already there but someone with a little bit of design experience and GTK+ knowledge, although neither is necessary.
Difficulty: Medium
Related issue(s): https://github.com/coala-analyzer/coala-gui/issues/9
Possible mentor(s): @Udayan12167
We want coala to run automatically if the project files changes and some other conditions under which it runs automatically and generates results in the GUI. This is small project could be clubbed with another.
Difficulty: Medium
Related issue(s): https://github.com/coala-analyzer/coala-gui/issues/10
coala