├── .ci ├── build.sh ├── check_maintainership.sh ├── check_moban.sh └── rultor_secrets.sh.asc ├── .coafile ├── .editorconfig ├── .gitignore ├── .moban.yaml ├── .ruby-version ├── .rultor.yml ├── .travis.yml ├── 404.html ├── CNAME ├── Gemfile ├── Gemfile.lock ├── LICENSE ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── _config.yml ├── _faq ├── application-template.md ├── cep-and-its-importance.md ├── coala-will-apply-for-gsoc.md ├── contact-mentor.md ├── gsoc-requirements.md ├── high-involvement-status.md ├── i-want-to-do-a-gsoc.md ├── is-mentor-necessary.md ├── mentor-obligations.md ├── own-project-idea.md ├── project-participation.md ├── steal-project-idea.md ├── student-obligations.md ├── thesis.md ├── working-out-the-proposal.md └── writing-a-great-proposal.md ├── _layouts └── report.md ├── _projects ├── README.md ├── add-repo-license.md ├── antlr-v4.md ├── aspects.md ├── assign-issues.md ├── automate-dependency-repology.md ├── automate-vulture-whitelist.md ├── bear-updates.md ├── coala-cli.md ├── coala-language-server.md ├── coala-web.md ├── cobot-enhancement.md ├── commit-based-perftest.md ├── commit-content-checks.md ├── communication-bridge.md ├── convert-bear-to-aspects.md ├── corobo-enhancement.md ├── create-jenkins-plugin.md ├── debug-profile.md ├── django-microfarm.md ├── documentation-extraction.md ├── editor-support.md ├── enhance-and-improve-coala-community-and-projects-website.md ├── enhance-coala-quickstart.md ├── example.md ├── extend-linter-integration.md ├── generic-bears.md ├── git-bug.md ├── git-bug2.md ├── git-task-list.md ├── gitmate-coala.md ├── gitmate-gitlab.md ├── gitmate-jira.md ├── gitmate-plugins.md ├── gitmate-testing.md ├── go-bears-on-bsd.md ├── i-gitt-scm-support.md ├── implement-aspects.md ├── implement-metrics-for-coala.md ├── improve-corobo.md ├── improve-diff-handling.md ├── improve-installation.md ├── integrate-pyflakes-AST.md ├── jetbrains-ide-plugin.md ├── meta-review.md ├── nested-languages.md ├── newcomer-metrics.md ├── nextgen-action-system.md ├── optimize-caching.md ├── pr-perftest.md ├── python-support.md ├── quickstart-green-mode.md ├── result-reporter-tool.md ├── roberta-external-source.md ├── rstcheck-with-better-sphinx-support.md ├── standardised-file-format.md ├── use-coala-2.md ├── use-coala-3.md ├── use-coala.md └── vulture.md ├── _reports ├── A-Hilaly.md ├── AlexMaxim.md ├── AmolGrover.md ├── GuangyuanYang.md ├── HemangKumar.md ├── KVGarg.md ├── MeetMangukiya.md ├── NaveenKumarSangi.md ├── Naveenaidu.md ├── NitanshuVashistha.md ├── PrajwalM.md ├── RJ722.md ├── RahulJha.md ├── RaiVaibhav.md ├── RohanVB.md ├── Utkarsh1308.md ├── VamshiKrishna.md ├── adhikasp.md ├── akshatkarani.md ├── bkhanale.md ├── chay2199.md ├── example.md ├── ishanSrt.md ├── kriti21.md ├── ksdme.md ├── li-boxuan.md ├── macbox7.md ├── palash25.md ├── pareksha.md ├── pilgrim2308.md ├── pra17dod.md ├── saksham.md ├── satwikkansal.md ├── shrikrishna.md └── virresh.md ├── book.json ├── data ├── admins.json ├── faq.liquid ├── locale │ ├── LANGS.md │ ├── en │ │ ├── README.md │ │ ├── SUMMARY.md │ │ ├── book.json │ │ ├── faq │ │ └── projects │ ├── hi │ │ └── faq.json │ ├── id │ │ ├── README.md │ │ ├── SUMMARY.md │ │ ├── book.json │ │ ├── faq.json │ │ ├── faq │ │ │ ├── coala-will-apply-for-gsoc.md │ │ │ └── contact-mentor.md │ │ ├── projects.json │ │ └── projects │ │ │ └── roberta-external-source.md │ └── ro │ │ └── faq.json └── projects.liquid ├── favicon.ico ├── index.html ├── netlify.toml ├── partials └── tabs │ ├── faq.html │ ├── mentors.html │ ├── projects.html │ └── students.html ├── reports.html ├── resources ├── css │ ├── 404.css │ └── style.css ├── images │ ├── coala-404.png │ └── coala.png ├── js │ ├── analytics.js │ ├── app.js │ └── directives │ │ ├── faqs.js │ │ ├── mentors.js │ │ ├── projects.js │ │ └── students.js └── vendors │ ├── angular-sanitize │ └── angular-sanitize.js │ ├── bootstrap │ └── css │ │ └── bootstrap.min.css │ ├── markdown │ └── markdown.js │ ├── materialize │ └── css │ │ ├── materialize.css │ │ └── materialize.min.css │ └── showdown │ └── showdown.js ├── screenshots ├── header.png └── logo.png └── tools └── authorPatchCollector.py /.ci/build.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | set -e # halt script on error 3 | 4 | bundle exec jekyll build 5 | bundle exec htmlproofer ./_site \ 6 | --disable-external \ 7 | --only-4xx 8 | -------------------------------------------------------------------------------- /.ci/check_maintainership.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Do not use `set -x` here as then it displays the PYPIPW in logs 4 | set -e 5 | 6 | # Get environment variables, readily decrypted by rultor 7 | source ../rultor_secrets.sh 8 | 9 | # Make sure the user is a maintainer 10 | if curl "https://api.github.com/teams/1238757/memberships/${author}?access_token=${GITHUB_TOKEN}" | grep -q "Not Found"; then 11 | echo "@${author} is not in the maintainers group." 12 | exit 1 13 | fi 14 | -------------------------------------------------------------------------------- /.ci/check_moban.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -ex 4 | 5 | : "${MOBAN_BRANCH:=master}" 6 | 7 | git clone https://gitlab.com/coala/mobans \ 8 | --branch=${MOBAN_BRANCH} ../coala-mobans 9 | 10 | moban 11 | git diff --exit-code 12 | -------------------------------------------------------------------------------- /.ci/rultor_secrets.sh.asc: -------------------------------------------------------------------------------- 1 | -----BEGIN PGP MESSAGE----- 2 | 3 | hQEMA5qETcGag5w6AQgAh+zT6fGZ24R3Dn4D403/G5kwKBB5dr5WgQYdL6jyUJrN 4 | O5XatbOODhBstI6vjAE2TV8eT9jVwc1H2cP30wskh4qrAidB/rJkzFn1aO4wJTOd 5 | dCLuEXDPPPI9545YTNCpmqKYbdh9w16NepjwvgPAXS9G6JusFBlqjXpXsdtxqeoF 6 | VPpRABT2Sbau9Uz5o5EJ4OxTQeSRmG4YOimod8O7BSG3jUzFrkbNKLT68m01CSYi 7 | EoZFZMR8EMLZkvWEpqW/qm6zIS//p7cyJ+6Xq5OY6NIymMIE46ZBmS0VTEtuH+Y3 8 | haUFQjoBEVMjEAAFzN8vTT9XhJSxvJ8L/sf53f0pjNLAIQH4Rkcz0gj0teEMwfB8 9 | SsVNz5oEwer78MvkHXuVK7RW27sHeTKZLLqf2JAA1QKYZAG8N4VErGsvCixyvF5I 10 | mA/LEBHKbj5AABzzlCjMxAN5qiQnPJ+ajQTIrHMP3GrEdTwbLaqKnUtVa/PVBfpF 11 | Fp1V3Eo+5qGcET0SY+Z+u2X4wSNiYzMswowCLsIs6x7wGZ6lcMyy8+Cgz5zA9ZNJ 12 | UOTV/BNd8PO8U9GnwB0/pDQrEV6nRFm5bu92+UkywJUQH0bTSbpI+a9bGIpZHMF5 13 | RI5VVWG/ZbELGXwje5XswwHA6g== 14 | =52lT 15 | -----END PGP MESSAGE----- 16 | -------------------------------------------------------------------------------- /.editorconfig: -------------------------------------------------------------------------------- 1 | # EditorConfig is awesome: https://EditorConfig.org 2 | 3 | # top-most EditorConfig file 4 | root = true 5 | 6 | # Unix-style newlines with a newline ending every file 7 | [*] 8 | end_of_line = lf 9 | insert_final_newline = true 10 | 11 | # Matches multiple files with brace expansion notation 12 | # Set default charset 13 | [*.{js,py}] 14 | charset = utf-8 15 | 16 | # 4 space indentation 17 | [*.py] 18 | indent_style = space 19 | indent_size = 4 20 | 21 | # Tab indentation (no size specified) 22 | [Makefile] 23 | indent_style = tab 24 | 25 | # Indentation override for all JS under lib directory 26 | [lib/**.js] 27 | indent_style = space 28 | indent_size = 2 29 | 30 | # Matches the exact files either package.json or .travis.yml 31 | [{package.json,.travis.yml}] 32 | indent_style = space 33 | indent_size = 2 34 | -------------------------------------------------------------------------------- /.moban.yaml: -------------------------------------------------------------------------------- 1 | overrides: coala.yaml 2 | 3 | language: ruby 4 | gitignore_language: Jekyll 5 | gitignore_extra_rulesets: 6 | - GitBook 7 | 8 | configuration: 9 | template_dir: 10 | - ../coala-mobans/templates/ 11 | - ../coala-mobans/assets/ 12 | configuration: .moban.yaml 13 | configuration_dir: ../coala-mobans/ 14 | targets: 15 | - .gitignore: coala-gitignore.jj2 16 | -------------------------------------------------------------------------------- /.ruby-version: -------------------------------------------------------------------------------- 1 | 2.5.1 2 | -------------------------------------------------------------------------------- /.rultor.yml: -------------------------------------------------------------------------------- 1 | merge: 2 | fast-forward: only 3 | script: 4 | - bash .ci/check_maintainership.sh 5 | 6 | decrypt: 7 | rultor_secrets.sh: "repo/.ci/rultor_secrets.sh.asc" 8 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | services: docker 2 | 3 | language: ruby 4 | rvm: 5 | - 2.5.1 6 | cache: bundler 7 | 8 | .disable_global: &disable_global 9 | rvm: false 10 | cache: false 11 | before_install: [] 12 | install: [] 13 | script: [] 14 | 15 | env: 16 | global: 17 | - GRAVIS="https://raw.githubusercontent.com/DanySK/Gravis-CI/master/" 18 | - JDK="adopt@1.8.0-275" 19 | 20 | jobs: 21 | include: 22 | - stage: moban 23 | <<: *disable_global 24 | language: python 25 | python: 3.6 26 | cache: pip 27 | install: pip install moban 28 | script: .ci/check_moban.sh 29 | - stage: coala 30 | <<: *disable_global 31 | language: python 32 | python: 3.6 33 | cache: pip 34 | before_install: 35 | - curl "${GRAVIS}.install-jdk-travis.sh" 36 | --output ~/.install-jdk-travis.sh 37 | - source ~/.install-jdk-travis.sh 38 | - npm install -g csslint@^1.0.5 39 | install: 40 | - cOALA_ZIP_URL=https://github.com/coala/coala/archive/master.zip 41 | - curl -fsSL -o coala-master.zip $cOALA_ZIP_URL 42 | - pip install coala-master.zip 43 | - BEARS_ZIP_URL=https://codeload.github.com/coala/coala-bears/zip 44 | - curl -fsSL -o coala-bears.zip $BEARS_ZIP_URL/master 45 | - pip install coala-bears.zip[alldeps] --pre -U 46 | script: coala --ci 47 | 48 | before_install: 49 | # Speeds installation of html-proofer 50 | - export NOKOGIRI_USE_SYSTEM_LIBRARIES=true 51 | 52 | # Assume bundler is being used, therefore 53 | # the `install` step will run `bundle install` by default. 54 | script: 55 | - .ci/build.sh 56 | 57 | notifications: 58 | email: false 59 | webhooks: https://www.travisbuddy.com/ 60 | on_success: never 61 | 62 | # Route your build to the container-based infrastructure for a faster build 63 | sudo: false 64 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | 5 | 6 | Page Not Found | {{ site.title }} 7 | 8 | 9 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 |
27 | missing coala in shock 28 |
29 |
30 |

Oops! That was unexpected...

31 |

coala couldn't find the page you're looking for.

32 |
33 | Crawl back home 34 |
35 |
36 |
37 | 43 | 50 | 51 | 52 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | projects.coala.io -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | ruby "2.5.1" 3 | 4 | gem "jekyll" 5 | gem "jekyll-netlify" 6 | gem "html-proofer" 7 | -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | activesupport (5.2.1) 5 | concurrent-ruby (~> 1.0, >= 1.0.2) 6 | i18n (>= 0.7, < 2) 7 | minitest (~> 5.1) 8 | tzinfo (~> 1.1) 9 | addressable (2.5.2) 10 | public_suffix (>= 2.0.2, < 4.0) 11 | colorator (1.1.0) 12 | colorize (0.8.1) 13 | concurrent-ruby (1.0.5) 14 | em-websocket (0.5.1) 15 | eventmachine (>= 0.12.9) 16 | http_parser.rb (~> 0.6.0) 17 | ethon (0.11.0) 18 | ffi (>= 1.3.0) 19 | eventmachine (1.2.7) 20 | ffi (1.9.25) 21 | forwardable-extended (2.6.0) 22 | html-proofer (3.9.2) 23 | activesupport (>= 4.2, < 6.0) 24 | addressable (~> 2.3) 25 | colorize (~> 0.8) 26 | mercenary (~> 0.3.2) 27 | nokogiri (~> 1.8.1) 28 | parallel (~> 1.3) 29 | typhoeus (~> 1.3) 30 | yell (~> 2.0) 31 | http_parser.rb (0.6.0) 32 | i18n (0.9.5) 33 | concurrent-ruby (~> 1.0) 34 | jekyll (3.8.3) 35 | addressable (~> 2.4) 36 | colorator (~> 1.0) 37 | em-websocket (~> 0.5) 38 | i18n (~> 0.7) 39 | jekyll-sass-converter (~> 1.0) 40 | jekyll-watch (~> 2.0) 41 | kramdown (~> 1.14) 42 | liquid (~> 4.0) 43 | mercenary (~> 0.3.3) 44 | pathutil (~> 0.9) 45 | rouge (>= 1.7, < 4) 46 | safe_yaml (~> 1.0) 47 | jekyll-netlify (0.2.0) 48 | jekyll (~> 3.0) 49 | jekyll-sass-converter (1.5.2) 50 | sass (~> 3.4) 51 | jekyll-watch (2.0.0) 52 | listen (~> 3.0) 53 | kramdown (1.17.0) 54 | liquid (4.0.0) 55 | listen (3.1.5) 56 | rb-fsevent (~> 0.9, >= 0.9.4) 57 | rb-inotify (~> 0.9, >= 0.9.7) 58 | ruby_dep (~> 1.2) 59 | mercenary (0.3.6) 60 | mini_portile2 (2.3.0) 61 | minitest (5.11.3) 62 | nokogiri (1.8.4) 63 | mini_portile2 (~> 2.3.0) 64 | parallel (1.12.1) 65 | pathutil (0.16.1) 66 | forwardable-extended (~> 2.6) 67 | public_suffix (3.0.2) 68 | rb-fsevent (0.10.3) 69 | rb-inotify (0.9.10) 70 | ffi (>= 0.5.0, < 2) 71 | rouge (3.2.0) 72 | ruby_dep (1.5.0) 73 | safe_yaml (1.0.4) 74 | sass (3.5.7) 75 | sass-listen (~> 4.0.0) 76 | sass-listen (4.0.0) 77 | rb-fsevent (~> 0.9, >= 0.9.4) 78 | rb-inotify (~> 0.9, >= 0.9.7) 79 | thread_safe (0.3.6) 80 | typhoeus (1.3.0) 81 | ethon (>= 0.9.0) 82 | tzinfo (1.2.5) 83 | thread_safe (~> 0.1) 84 | yell (2.0.7) 85 | 86 | PLATFORMS 87 | ruby 88 | 89 | DEPENDENCIES 90 | html-proofer 91 | jekyll 92 | jekyll-netlify 93 | 94 | RUBY VERSION 95 | ruby 2.5.1p57 96 | 97 | BUNDLED WITH 98 | 1.16.2 99 | -------------------------------------------------------------------------------- /PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 7 | 8 | **For short term contributors:** we understand that getting your commits well 9 | defined like we require is a hard task and takes some learning. If you 10 | look to help without wanting to contribute long term there's no need 11 | for you to learn this. Just drop us a message and we'll take care of brushing 12 | up your stuff for merge! 13 | 14 | ### Checklist 15 | 16 | - [ ] I read the [commit guidelines](http://coala.io/commit) and I've followed 17 | them. 18 | - [ ] I ran coala over my code locally. (*All commits have to pass 19 | individually.* It is not sufficient to have "fixup commits" on your PR, 20 | our bot will still report the issues for the previous commit.) You will 21 | likely receive a lot of bot comments and build failures if coala does not 22 | pass on every single commit! 23 | 24 | After you submit your pull request, **DO NOT click the 'Update Branch' button.** 25 | When asked for a rebase, consult [coala.io/rebase](https://coala.io/rebase) 26 | instead. 27 | 28 | Please consider helping us by reviewing other peoples pull requests as well: 29 | 30 | - pick up any PR at 31 | - review it (check for more info) 32 | - if you are sure that it needs work, use `cobot mark wip ` to get it out 33 | of the review queue. 34 | 35 | The more you review, the more your score will grow at coala.io and we will 36 | review your PRs faster! 37 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | # Projects 4 | 5 | A website that showcases projects! **If you want to use it and it's not exactly 6 | fitting your purpose, please do make upstream changes. We expect this project 7 | to be of use to others and we're happy to make it more generic so it's easier 8 | to adapt to other organizations.** This was built by coala community, to view 9 | live projects visit [projects.coala.io](https://projects.coala.io) 10 | 11 | (It'd be nice to have an organization YML or so e.g.) 12 | 13 | ## Purpose 14 | 15 | This is designed for GSoC but can be used for other initiatives at the same 16 | time. We use it for research theses, GSoC, GCI and maybe others in the future. 17 | 18 | Why? 19 | 20 | - It's way more appealing to students. 21 | - You can search and filter projects. 22 | - Project ideas as structured data are more concise and you're sure to have all 23 | points covered - at the same time we can show students an overview and showing 24 | the full information only when needed. 25 | - A proper review process can be used for triaging and iterating on project 26 | ideas. 27 | - Stop wasting time maintaining a mentors list. This can be generated from the 28 | projects. 29 | 30 | ## Usage 31 | 32 | ### Dependencies 33 | 34 | 1. Install [asdf-vm](https://asdf-vm.github.io/asdf/#/core-manage-asdf-vm) for your OS. 35 | 2. Using asdf-vm, install [ruby](https://github.com/asdf-vm/asdf-ruby). 36 | 3. Install Jekyll 37 | 38 | $ gem install jekyll bundler 39 | 40 | ### Clone and Run 41 | 42 | Clone coala Projects repository 43 | 44 | $ git clone https://github.com/coala/projects.git 45 | 46 | Run coala Projects website 47 | 48 | $ cd projects 49 | $ bundle install 50 | $ bundle exec jekyll serve 51 | 52 | Then you can simply go to either of the following addresses in your browser to access the site: 53 | 54 | 127.0.0.1:4000 55 | localhost:4000 56 | 57 | If you face problems while installing Jekyll or using its gem bundler you may go through its [troubleshooting docs](https://jekyllrb.com/docs/troubleshooting/) 58 | 59 | ## Defining Projects 60 | 61 | Mentors and admins can define projects in markdown using the following structure and save it in the ``_projects`` folder with a relevant filename. 62 | A sample project definition is available [here](https://github.com/coala/projects/blob/master/_projects/example.md) 63 | 64 | ## Defining FAQs 65 | 66 | Users can also add FAQs by simply creating a markdown file in _faq folder. 67 | 68 | Format for faq markdown file is as follows: 69 | ``` 70 | --- 71 | Question: 72 | --- 73 | 74 | Answer 75 | ``` 76 | 77 | ## Multi Language Support 78 | 79 | coala Projects supports multiple 'human languages'. To add a translation of a project 80 | in a language, the following steps can be followed: 81 | 82 | - Create a folder with language code in ```data/locale``` folder. 83 | - Create ```faq.json```, ```projects.json```, ```faq``` and ```projects``` folder 84 | if they do not exist already. 85 | - Add translated content of a project inside ```projects``` folder. The names of the 86 | files should be the same. 87 | - Similarly translated content of a faq goes inside ```data/locale/ < language-id > /faq``` 88 | folder. 89 | - For the faq.json and projects.json metadata, refer to Bahasa and Hindi 90 | Translations available in ```data/locale``` directory. 91 | - Lastly, in ```resources/js/app.js``` file, Add the new language json in Language service. 92 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | title: coala Projects 2 | license: 3 | full_form: GNU AFFERO GENERAL PUBLIC LICENSE V3.0 4 | short_form: GNU AGPL v3.0 5 | organization: coala 6 | description: A website that showcases interesting projects, using Angular JS. 7 | baseurl: "" # the subpath of your site, e.g. /blog 8 | url: "" # the base hostname & protocol for your site 9 | githuburl: "https://github.com/coala/projects" 10 | 11 | gitter: 12 | gsoc: 13 | room: "https://gitter.im/coala/coala/gsoc" 14 | 15 | gsoc_switch_month: 6 16 | 17 | org: 18 | site_links: 19 | documentation: "https://coala.io/docs" 20 | newcomer_doc: "https://coala.io/newcomer" 21 | code_of_conduct: "https://coala.io/coc" 22 | blog: "https://blog.coala.io" 23 | 24 | twitter: 25 | username: coala_io 26 | 27 | plugins: 28 | - jekyll-netlify 29 | 30 | # Build settings 31 | exclude: [vendor, _projects/example.md] 32 | markdown: kramdown 33 | collections: 34 | projects: 35 | output: true 36 | reports: 37 | output: true 38 | faq: 39 | output: true 40 | 41 | defaults: 42 | - scope: 43 | path: '' 44 | type: reports 45 | values: 46 | layout: report 47 | permalink: GSoC/:year/StatusReport/:title 48 | -------------------------------------------------------------------------------- /_faq/cep-and-its-importance.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What is a cEP? Why is it so important to do a pre-GSoC analysis 3 | and design a proposal as early as possible?" 4 | --- 5 | A **cEP (coala Enhancement Proposal)** is proposed to the **coala** community 6 | to discuss the new *major features* that the contributor intends to implement 7 | during GSoC. The proposal is designed before the implementation of *major 8 | features* because the implementation usually happens from a technical 9 | perspective which may lead to a poorly designed content, both developer-wise 10 | and user-wise. So, to avoid this, a cEP should be designed at an earlier stage 11 | as this also saves a lot of coding work and makes sure that the major features 12 | are properly documented. 13 | 14 | Experience tells us that the best GSoC students are the ones who heavily 15 | contribute to the project ideas' website, create projects from the issues, and 16 | expand on the existing ***.md*** files. 17 | 18 | So, if you are planning to participate in GSoC with coala, you should start by 19 | writing a detailed project idea in our [projects](https://github.com/coala/projects) 20 | repository. Also, enough research about the project of interest must be done, 21 | so that you're able to express your ideas, timeline, etc clearly in your GSoC 22 | proposal as this will increase your chances of success. 23 | 24 | For more information and to learn more about writing a cEP, refer to the 25 | [cEP repository](https://github.com/coala/cEPs). 26 | -------------------------------------------------------------------------------- /_faq/coala-will-apply-for-gsoc.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "Will coala apply for Google Summer of Code next year?" 3 | --- 4 | Yes, coala will apply as an organisation for Google Summer of Code next year. You might read the [GSoC Timeline](https://developers.google.com/open-source/gsoc/timeline) to get an idea of how things will proceed. 5 | -------------------------------------------------------------------------------- /_faq/contact-mentor.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "I found a great project! How can I contact my mentor?" 3 | --- 4 | Almost all mentors are active on [gitter](https://coala.io/chat). 5 | Just drop by and leave us a message! In addition, most mentors have their 6 | mail addresses exposed on their GitHub profile. 7 | -------------------------------------------------------------------------------- /_faq/gsoc-requirements.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What are the requirements to be accepted for GSoC?" 3 | --- 4 | Other than the [requirements from Google](https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation) you will have to meet the following: 5 | 6 | * You have completed the [coala Newcomers guide](https://coala.io/newcomer) 7 | * You have a submission to [our usability survey](https://coala.io/usability) 8 | so we know that you know how to *use coala*. 9 | -------------------------------------------------------------------------------- /_faq/high-involvement-status.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What is the meaning of High Involvement status of any project?" 3 | --- 4 | 5 | It simply means that the project already has more than one proposal and if you 6 | want to submit the proposal for the project, you should make sure that your 7 | proposal should have some extra elements with a clear concept. 8 | Since we can't accept two proposals for the same project, the best solution will be 9 | that you should choose any other project to write a proposal. 10 | 11 | In simple language your proposal should be freaking awesome. 12 | -------------------------------------------------------------------------------- /_faq/i-want-to-do-a-gsoc.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "I want to do a GSoC!" 3 | --- 4 | Great! This is the right place. Check out the other questions and 5 | most importantly the projects page. 6 | -------------------------------------------------------------------------------- /_faq/is-mentor-necessary.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "A showcased project on the website doesn't have a mentor, but 3 | I'm interested in that project?" 4 | --- 5 | You just have to choose a project and write an awesome proposal. 6 | Mentors are set after we choose the projects (which is done by choosing the students). 7 | 8 | Our policy is that we'll always mentor awesome projects, so as long as your proposal 9 | is one of the winning ones, there will be a mentor for the project. 10 | But as for all other projects it might help to talk to your possible mentors, and in 11 | that case it also means trying to maybe find a mentor or at least talk to 12 | devs/maintainers about your ideas possibly on [gitter](https://coala.io/chat). 13 | -------------------------------------------------------------------------------- /_faq/mentor-obligations.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What are my obligations as a mentor during the GSoC?" 3 | --- 4 | coala has two mentors for every project: 5 | 6 | 1. **Primary mentor**: responsible for the administrative tasks of the project. 7 | 2. **Secondary mentor**: has little to no responsibility, but provides backup 8 | and code review for aspects of the project which are relevant to their 9 | expertise. 10 | 11 | We expect you to: 12 | 13 | * Be active on [gitter](https://coala.io/chat). 14 | * Blog at least once per milestone (this will be aggregated on 15 | [blog.coala.io](https://blog.coala.io)). 16 | Participate in weekly meetings with your student. 17 | * Review your students pull requests timely. 18 | * Get in contact with the admins if any even remotely 19 | potential problems arise. 20 | 21 | If you are interested in mentoring, please contact one of the admins 22 | indicating the reason your open source project is suitable to be included as 23 | a project to be mentored under the coala administrative umbrella. 24 | 25 | List of admins is [here](http://projects.coala.io/#/mentors). 26 | -------------------------------------------------------------------------------- /_faq/own-project-idea.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "I have an own project idea! (Mentors and students!)" 3 | --- 4 | Superb! We recommend you submit your idea to [our projects 5 | repository](https://github.com/coala/projects) as a pull request. 6 | -------------------------------------------------------------------------------- /_faq/project-participation.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "Do all listed projects will be part of GSoC (or any other initiative)?" 3 | --- 4 | No. 5 | We have way too many projects and you are even invited to add your own ideas. 6 | This means that the listed projects are just ideas for you. 7 | 8 | But as long as we have good applications and spots, projects will happen. 9 | Where there are good students, good projects will happen ;) 10 | -------------------------------------------------------------------------------- /_faq/steal-project-idea.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What happens if someone steals my unique idea for solving a project?" 3 | --- 4 | The whole point of "Open Source Software" is to encourage celebration of 5 | complete independence in sharing and writing code. 6 | If you do honor original authors, licenses, and the "creator" of an original 7 | idea, there is no shame in saying "he had a great idea, I think I can implement 8 | it". 9 | It's called "collaboration". 10 | Note though, that not following licenses and not disclosing an original 11 | creator of something is considered stealing and can have legal consequences. 12 | On the plus side, we will always take into account who came up with something 13 | and if you help others succeed, we'll definitely credit you for that. 14 | Most importantly, we want our contributors to work as a team and not like some 15 | "lone hackers" keeping secrets from fellow contributors, and sending 16 | unnecessary private messages to the project mentors. 17 | 18 | -------------------------------------------------------------------------------- /_faq/student-obligations.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "What are my obligations as a student during the GSoC?" 3 | --- 4 | We expect you to: 5 | 6 | * Be active on [gitter](https://coala.io/chat). 7 | * Blog at least once per week (this will be aggregated on 8 | [blog.coala.io](https://blog.coala.io)). 9 | * Participate in weekly meetings with your mentor. 10 | * Review PRs of other students and contributors. This is a big part of open 11 | source work and we'll make sure to help you get started. 12 | * All code you want to merge has to have full test coverage and documentation. 13 | * If anything, for whatever reason, looks 14 | to be problematic, talk to your mentor or an admin! 15 | 16 | And Again: 17 | __Get in contact with your mentors or the admins if any even remotely 18 | potential problems arise!__ 19 | -------------------------------------------------------------------------------- /_faq/thesis.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "I want to write a thesis with coala!" 3 | --- 4 | Great! This is the right place. Check out the other questions and most 5 | importantly the projects page. 6 | If you have own ideas we recommend you submit them to our [projects 7 | repository](https://github.com/coala/projects) as a pull request 8 | regardless if you want to do them yourself or not. 9 | You can find further information regarding thesis writing with coala 10 | [here](http://coala.io/thesis). 11 | -------------------------------------------------------------------------------- /_faq/working-out-the-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "When should I start working out the proposal?" 3 | --- 4 | You can start right now! Ping any mentor and start discussing. 5 | The earlier you start, the better! 6 | -------------------------------------------------------------------------------- /_faq/writing-a-great-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | question: "How do I work out a great proposal?" 3 | --- 4 | Please design your project in a way that you have **multiple 5 | checkpoints**. We'd like you to specify at least three milestones with 6 | specific goals: if something goes wrong for a valid reason, we can rearrange 7 | your schedule meaningfully. Each of those goals has to be merged into the main 8 | coala codebase in order for it to be considered"complete". You should be 9 | aware of what that involves for you (writing tests, writing docs, going 10 | through extensive code review, learning :), reiterating). 11 | 12 | You can use any project idea listed here or one that came out of your mind - 13 | however be sure to make us aware of your plans and start planning your project 14 | with us so we can coordinate and - in the worst case - prohibit waste of time 15 | from your side. At all cost make sure you find something that interests you. 16 | We want this to be a fun and educating experience for you! 17 | 18 | Use the"draft" feature on the GSoC system, submit your draft early, get a 19 | lot of helpful feedback from us! 20 | 21 | 22 | #### Writing the proposal 23 | 24 | Please follow the **application template** in the faq. 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. 25 | 26 | For writing your proposal we recommend using [Google Docs](https://www.google.com/docs/about/) as this will be supported by the Google submission system. 27 | 28 | If needed, you can get further information about GSoC [here](https://summerofcode.withgoogle.com/). 29 | -------------------------------------------------------------------------------- /_projects/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/_projects/README.md -------------------------------------------------------------------------------- /_projects/antlr-v4.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - ANTLRv4 5 | desc: "This project is about integrating ANTLR into the coala bear API. " 6 | difficulty: high 7 | initiatives: 8 | - GSoC18 9 | - RGSoC 10 | issues: [] 11 | markdown: antlr-v4.md 12 | mentors: 13 | - Udayan12167 14 | - corona10 15 | - aptrishu 16 | name: "Integrate ANTLR v4 into coala" 17 | requirements: 18 | - "The participant should have one patch to [coala](https://github.com/coala/coala) accepted." 19 | - "Being familiar with the current Bear API and what it provides." 20 | - "Knowledge of ANTLR and Java is a bonus." 21 | - "Knowledge of ASTs and basic language grammar." 22 | status: completed 23 | tags: 24 | - API 25 | - AST 26 | - Bears 27 | --- 28 | 29 | ANTLR (ANother Tool for Language Recognition) is a powerful parser generator 30 | for reading, processing, executing, or translating structured text or binary 31 | files. It's widely used to build languages, tools, and frameworks. From a 32 | grammar, ANTLR generates a parser that can build parse trees and also 33 | generates a listener interface (or visitor) that makes it easy to respond to 34 | the recognition of phrases of interest. 35 | 36 | Thus ANTLR allows us to create an AST for any programming language we have a 37 | grammar for. Having an abstract syntax tree allows us to write advanced 38 | algorithms for static analysis. What we are looking for in this project is to 39 | have an AST interface within the Bear class. Basically, the Bear writer 40 | provides a flag which lets them traverse the AST of any language source code 41 | they provide. 42 | 43 | Hence this project has two targets: 44 | 45 | - Successful integration of ANTLR into the coala core providing the user with an AST interface when writing a Bear. 46 | - Writing a basic Bear which tests this functionality using the AST. 47 | 48 | References: 49 | 50 | - [ANTLR](https://github.com/antlr/antlr4) 51 | - [Grammars](https://github.com/antlr/grammars-v4) 52 | 53 | #### Milestones 54 | 55 | ##### PREPARATION/BONDING 56 | 57 | - A clear understanding of ANTLR python endpoints and conceptual knowledge of 58 | how ANTLR works. 59 | - A cEP of how the AST API inside a bear will work and be accessible to the 60 | developer writing the bear. 61 | - A plan for a caching mechanism of language grammars from the 62 | [Grammars](https://github.com/antlr/grammars-v4) repository. 63 | 64 | ##### CODING PHASE 1 65 | 66 | - Bear API for ASTs is done and well documented. 67 | - Testing of the API has begun and most of the areas have been covered. 68 | - A proposal for the sample Bear that is going to implemented. 69 | 70 | ##### CODING PHASE 2 71 | 72 | - The API is merged into coala. 73 | - The implementation for the sample bear is completed and testing has begun. 74 | 75 | ##### CODING PHASE 3 76 | 77 | - The Bear is merged and documented. 78 | - A tutorial is merged which contains instructions on how to write a Bear 79 | using the AST API. 80 | -------------------------------------------------------------------------------- /_projects/aspects.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "This project is about collecting bears based on aspects that the user wants to have checked." 5 | developers_involved: [] 6 | difficulty: high 7 | status: completed 8 | initiatives: 9 | - GSoC 10 | - RGSoC 11 | issues: [] 12 | markdown: implement-aspects.md 13 | mentors: 14 | - userzimmermann 15 | - jayvdb 16 | - myint 17 | name: "Implement Aspects Support" 18 | requirements: 19 | - "The participant should have one patch to any bear accepted." 20 | - "The participant should have one patch to the coala core accepted." 21 | - "The participant should have a solid understanding of 22 | [cEP-0005](https://github.com/coala/cEPs/blob/mzaster/cEP-0005.md)." 23 | - "The participant should have a solid understanding of 24 | [cEP-0002](https://github.com/coala/cEPs/blob/master/cEP-0002.md)." 25 | tags: 26 | - Core 27 | - Bears 28 | - Aspects 29 | --- 30 | 31 | coala offers quite a number of bears to its users, many of them wrapping 32 | existing linters. 33 | Although coala offers benefits in usability by utilising a single configuration 34 | file and user interface, there is one last big obstacle left, from our point 35 | of view. 36 | Until now, developers have to know which tools offer a certain analysis. 37 | So if you for example want to have unused code detection for python, you have 38 | to find a tool like Vulture. 39 | Without coala you'd also have to learn how to use Vulture. But even coala does 40 | not help you with finding a tool that can detect unused code in python so far. 41 | 42 | This is where aspects do their work. 43 | We could say, an aspect is a kind of analysis we want to run over the code. 44 | For example, "UnusedCode" could be an aspect that describes analysis routines, 45 | that will detect code that is never reached. 46 | Now if a user wants to detect unused code, instead of stating which bear coala 47 | should use, which requires the user to know bears/tools and their options, 48 | they can simply add the "UnusedCode" aspect and coala will figure out what 49 | bears must be used and how to use them. 50 | 51 | The goal of this project is to create the aspects categories and annotate 52 | results of bears with them. 53 | This is what makes the aspects available to users and has to be built into each 54 | bear individually. 55 | 56 | References 57 | 58 | * Aspects concept based on 59 | [cEP-0005](https://github.com/coala/cEPs/blob/master/cEP-0005.md) 60 | * Proposal on how new bears could be designed 61 | [cEP-0002](https://github.com/coala/cEPs/blob/master/cEP-0002.md) 62 | * Current aspects prototype 63 | [coala/aspect-docs](https://github.com/coala/aspect-docs) 64 | 65 | #### Milestones 66 | 67 | ##### PREPARATION/BONDING 68 | 69 | * The names and settings of the needed aspects are drafted completely. 70 | 71 | ##### CODING PHASE 1 72 | 73 | * A third of the defined aspects are properly defined, documented and merged. 74 | * A third of the defined bears return results with aspects. 75 | 76 | ##### CODING PHASE 2 77 | 78 | * Two thirds of the defined aspects are properly defined, documented and merged. 79 | * Two thirds of the defined bears return results with aspects. 80 | 81 | ##### CODING PHASE 3 82 | 83 | * All of the defined aspects are properly defined, documented and merged. 84 | * All of the defined bears return results with aspects. 85 | -------------------------------------------------------------------------------- /_projects/assign-issues.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - GitMate 5 | desc: "Make sure that developers get notified about new issues that need their 6 | input: Use the tags of the new issue to find developers that have 7 | previously solved similar Issues." 8 | difficulty: high 9 | status: completed 10 | initiatives: 11 | - Research 12 | issues: [] 13 | markdown: assign-issues.md 14 | mentors: 15 | - fneu 16 | - sils 17 | name: "Tag-based Assignment of Developers to Issues" 18 | requirements: 19 | - "At least one patch to coala or GitMate should be accepted and merged." 20 | - "Familiarity with [IGitt](https://gitlab.com/gitmate/IGitt) is advised." 21 | tags: 22 | - Workflow 23 | - GitHub 24 | --- 25 | 26 | Issues are the primary way to organize developer tasks for projects on GitHub including coala. 27 | The progress of these projects oftentimes relies on the right developers being notified of 28 | new issues that fall into their territory of expertise. 29 | With the project growing, the number of incoming issues increases. Not all developers can continuously 30 | scan all incoming issues. It is therefore likely that developers miss issues that they could have 31 | great influence on with little investment. 32 | 33 | The goal of this project is to analyse incoming issues and evaluate the issue title, text, and tags to 34 | determine the developer(s) most likely to be familiar with the task or problem at hand. 35 | 36 | The scope of this project is aimed at a scientific research thesis. Therefore we would like to see a 37 | clearly determined and structured approach as to how the appropriate developers will be selected. 38 | Most appropriate would be a literature-backed approach that is implemented and verified throughout the 39 | execution of this project. 40 | 41 | #### Milestones 42 | 43 | ##### PROPOSAL 44 | 45 | * A credible strategy for selecting developers is proposed 46 | 47 | ##### EVALUATION 48 | 49 | * The data of previous developer activity has been collected and processed 50 | * A toolchain is in place to automatically collect and evaluate incoming issues 51 | * The proposed developer selection algorithm has been implemented 52 | * The developer selection done by the algorithm has been verified or refuted 53 | -------------------------------------------------------------------------------- /_projects/automate-dependency-repology.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - repology 4 | - coala 5 | desc: "Improve coala's dependency installation and management, by automating using data from repology." 6 | difficulty: medium 7 | initiatives: 8 | - GSoC18 9 | - RGSoC 10 | issues: 11 | - "https://gitlab.com/coala/package_manager/issues/159" 12 | - "https://github.com/coala/coala/issues/4605" 13 | - "https://github.com/repology/repology/issues/512" 14 | markdown: automate-dependency-repology.md 15 | mentors: 16 | - waldyrious 17 | - fexpr 18 | - underyx 19 | name: "Automation of Dependency Management using Repology" 20 | requirements: 21 | - "At least one patch to the coala core should be accepted and merged." 22 | - "The proposal needs to show some familiarity with coala's dependency management implementation." 23 | status: disabled 24 | tags: 25 | - Automation 26 | - Installation 27 | - Dependency 28 | - Web 29 | --- 30 | 31 | **coala-bears** are of two types, Native Bears which implement all the buisness 32 | logic themselves and Linter Bears which wrap existing linters and checkers. 33 | 34 | These Linter Bears have dependencies which need to be installed before they can 35 | be executed. In this project, you're to improve on the current strategies of 36 | installing these dependencies. 37 | 38 | Repology is a packaging hub. It analyzes a lot of package repositories and 39 | other sources, comparing packages versions across them and gatherinng relevant 40 | information. It shows you in which repositories a given project is packaged, 41 | which version is the latest and which needs updating, who maintains the 42 | package, and other related information. The student has to use this information 43 | and implement improvments to the automated management of dependencies. 44 | 45 | The scope of a complete soultion is too large. The student should come up with 46 | suitable scope and make a proposal accordingly. 47 | 48 | #### Milestones 49 | 50 | ##### PREPARATION/BONDING 51 | 52 | * The applicant has identified most of the related problems. 53 | * The applicant has came up with a complete workflow of how dependencies would 54 | be managed across multiple operating systems and package managers. 55 | * The Student has at least one Linter Bear connected with Repology ID. 56 | 57 | ##### CODING PHASE 1 58 | 59 | * All the existing LinterBears and Package Manager classes are connected with their respective Repology IDs. 60 | * Documentation added on how to do the same for new Linter Bears to 61 | [Writing Linter Bears](https://api.coala.io/en/latest/Developers/Writing_Linter_Bears.html) 62 | 63 | ##### CODING PHASE 2 64 | 65 | * The applicant has implemented a system for fetching data from Repology. 66 | * The applicant has wrote sufficent tests and documentation for the same. 67 | * At least part of the scope has been implemented and tested. 68 | 69 | ##### CODING PHASE 3 70 | 71 | * The proposed scope is completly implemented and tested. 72 | -------------------------------------------------------------------------------- /_projects/automate-vulture-whitelist.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Automate Whitelist creation for vulture" 3 | collaborating_projects: 4 | - coala 5 | - vulture 6 | desc: "Automatically create whitelists and detect false positives for vulture." 7 | developers_involved: 8 | - RJ722 9 | mentors: 10 | - AbdealiJK 11 | - jendrikseipp 12 | - The-Compiler 13 | difficulty: medium 14 | status: completed 15 | initiatives: 16 | - GSoC18 17 | issues: 18 | - "https://github.com/jendrikseipp/vulture/issues/109" 19 | - "https://github.com/jendrikseipp/vulture/issues/8" 20 | markdown: automate-vulture-whitelist.md 21 | requirements: 22 | - "Familiarity with vulture" 23 | - "Knowledge of AST's" 24 | - "Experience working with coverage." 25 | - "A little know-how about PyQt and shiboken." 26 | tags: 27 | - Vulture 28 | - AST 29 | - coverage 30 | --- 31 | 32 | The main aim of this project is to automatically create whitelists (to be 33 | utilized by vulture) for projects projects using 34 | [`sip`](https://www.riverbankcomputing.com/software/sip/intro) and 35 | [`shiboken`](http://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/shiboken2) 36 | to generate Python bindings for C++ code, most significant of them being PyQt. 37 | Once implemented, a whitelist generated for PyQt (let's say) through this 38 | generator could then be universally utilised across all PyQt projects. 39 | 40 | #### IDEAS 41 | 42 | * Create a command line tool which takes in `sip` files as input and spits a 43 | whitelist with all the virtual functions defined in the `sip` files. (Add 44 | Documentation and tests) 45 | * Use this tool to generate a whitelist for PyQt and ship it with vulture. This 46 | will reduce overhead for PyQt projects which use vulture. 47 | * Allow passing coverage.xml to vulture via `--make-whitelist` and let it find 48 | the list of false-positive functions. (Add Documentation and tests as well) 49 | * Write a whitelist generator for shiboken, the binding generator used for 50 | PySide2. 51 | 52 | #### MILESTONES 53 | 54 | ##### COMMUNITY BONDING 55 | * Discussion on whether to implement a new Tracer or to directly consume `XML` 56 | output from `coverage.py`. 57 | * Get familiar with `coverage.xml`. 58 | * Take up small tasks from 59 | [TODO](https://github.com/jendrikseipp/vulture/tree/master/TODO.rst). 60 | 61 | ##### CODING PHASE 1 62 | * The whitelist generator should be completely implemented. 63 | * It should reside in it's own repository, with CI enabled for testing on both 64 | the GNU/Linux and Windows platforms. CI should also ensure ongoing support 65 | for py2.7 & py3.4+ for compatibility with vulture. 66 | * Write tests, achieve 100% code coverage. 67 | * It should be gracefully documented. 68 | * A whitelist for PyQt should be generated to be then shipped with vulture by 69 | default, thus helping PyQt projects like 70 | [qutebrowser](https://github.com/qutebrowser/qutebrowser) to deal with false 71 | positives. 72 | * Maximise code coverage of vulture. 73 | 74 | ##### CODING PHASE 2 75 | * `--make-whitelist`: Vulture should be able to find a list of false positives 76 | (for functions and methods) from `coverage.xml`. 77 | * Maintain code coverage, robust tests should be written. 78 | * Add documentation, how-to, examples and use cases in 79 | [README](https://github.com/jendrikseipp/vulture/tree/master/README.rst). 80 | * Research and planning about how to generate whitelists for 81 | [`shiboken`](http://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/shiboken2). 82 | 83 | ##### CODING PHASE 3 84 | * Implement whitelist generator for 85 | [`shiboken`](http://code.qt.io/cgit/pyside/pyside-setup.git/tree/sources/shiboken2). 86 | * Add new tests, sustain code coverage. 87 | * Update documentation for the whitelist generator. 88 | -------------------------------------------------------------------------------- /_projects/bear-updates.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Fixing issues and improving documentation and testing of existing linter bears." 5 | difficulty: low 6 | initiatives: 7 | - GSoC 8 | - RGSoC 9 | issues: [] 10 | markdown: bear-updates.md 11 | mentors: 12 | - AbdealiJK 13 | - mixih 14 | name: "Improve Lint Bear Quality" 15 | requirements: 16 | - "The participant should have one bugfix patch to any bear accepted." 17 | - "The participant should have understanding of the linter and test framework for bears." 18 | - "The proposal should contain issues which are planned to be addressed, chosen 19 | (and potentially [filed](https://github.com/coala/coala-bears/issues/new)) by the student." 20 | status: disabled 21 | tags: 22 | - Documentation 23 | - Bears 24 | - Testing 25 | --- 26 | 27 | This project is about improving the general quality of coala's linter bears. 28 | 29 | Since it is very easy to write them even for very inexperienced contributors, 30 | linter bears in coala often suffer from mediocre quality, especially once they 31 | made it into the codebase. 32 | They do work, but not necessarily on all platforms or for all usecases. They are documented, but not 33 | necessarily understandable. They are tested, but lack corner cases or exploratory tests. 34 | [See existing issues](https://github.com/coala/coala-bears/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Flintbears) 35 | 36 | Students working on this project familiarize themselves in-depth with the 37 | working of the `linter` decorator and the existing linter bears. They identify 38 | systematic issues with the way linter bears are developed and maintained and 39 | work to fix those issues and improve and amend 40 | [existing documentation](http://api.coala.io/en/latest/Developers/Writing_Linter_Bears.html) 41 | to avoid them in the future. A number of existing bears is updated and improved to fit the new standards. 42 | 43 | Possible areas to investigate include: 44 | 45 | * Tests: As mentioned above, tests for linter bears are often kept to a 46 | minimum. They use hardcoded files embedded into the test file, which makes it 47 | cumbersome and ugly to add more test cases. 48 | * Support for underlying tool: The support for the underlying tool is mostly 49 | left to the contributers discretion. Students could come up with a guideline 50 | on how well a tool's options must be supported and documented or even 51 | automated ways to test for this (maybe via a bear?). 52 | 53 | #### Milestones 54 | 55 | ##### PREPARATION/BONDING 56 | 57 | * The student is familiar with the `linter` decorator and the ecosystem of available linter bears. 58 | * Systematic issues with the way bears are developed and maintained are identified. 59 | * For each of the identified issues a set of goals is defined which should be reached by the end of the program. 60 | 61 | ##### CODING PHASE 1 62 | 63 | * Ideas for how to solve each of the identified issues are drafted. 64 | If possible ways to automatically check bears are drafted. 65 | * Changes to the [linter bear documentation](http://api.coala.io/en/latest/Developers/Writing_Linter_Bears.html) 66 | to improve quality of future bears are proposed. 67 | * A list of bears which suffer from any of the identified issues is composed. 68 | 69 | ##### CODING PHASE 2 70 | 71 | * Working concepts of systematic fixes exists and can be demonstrated (e.g. a 72 | more convenient way to test, an automatic check for tool option support). 73 | * At least one of the bears identified in the previous step has been improved to fit the new standards. 74 | 75 | ##### CODING PHASE 3 76 | 77 | * Any systematic fixes are finished and available for other bear developers to use. 78 | * If applicable a system is in place to automatically detect issues in newly created linter bears. 79 | * The bears from the list identified in coding phase 1 have all been fixed and improved to fit the new standards. 80 | -------------------------------------------------------------------------------- /_projects/coala-web.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "This project aims to intensify usage of coala by developing well organised web interfaces." 5 | developers_involved: [] 6 | difficulty: medium 7 | status: completed 8 | initiatives: 9 | - GSoC17 10 | - RGSoC 11 | issues: 12 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/12" 13 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/35" 14 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/36" 15 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/37" 16 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/38" 17 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/39" 18 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/40" 19 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/41" 20 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/190" 21 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/191" 22 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/194" 23 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/195" 24 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/196" 25 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/197" 26 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/198" 27 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/199" 28 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/204" 29 | markdown: coala-web.md 30 | mentors: 31 | - sils 32 | - fneu 33 | name: "Improve coala website & supporting tools" 34 | requirements: 35 | - "At least one patch to each of coala-landing and coala-html should be accepted and merged." 36 | - "The student should be familiar with web design tools & trends." 37 | tags: 38 | - Web 39 | - Blog 40 | --- 41 | 42 | This project aims to increase the user base of coala and provide a web based 43 | interface to use coala on their projects. The project is conceptually built upon 44 | various previous projects (coala-gui, coala-html) which have helped us refine, 45 | redefine and revisit our GUI approach. 46 | 47 | By providing first time users a one click interface to obtain a coafile online 48 | and to run coala at coala.io on their projects by two means, by pasting the code 49 | in the given editor box, and by pasting the link to their GitHub repository in 50 | a link box. This will help them to get started with coala very easily. 51 | 52 | The next thing where the project will help us is that it will provide an 53 | effective bear search mechanism on coala.io by improving the current one, and 54 | this will benefit first time users and developers alike. Its this one tool 55 | where we will type the name of language or aspect on which the user wants to do 56 | analysis, and the appropriate bears would be filtered and displayed. 57 | 58 | For the community, having all the web interfaces and UI elements in one place 59 | will provide a great headstart to any web project in the community. Apart from 60 | that, this project will help projects.coala.io become configurable. With these 61 | implemented, those who have their use cases similar to ours will easily be able 62 | to integrate these UI components with just one link, and get a projects page of 63 | their own in seconds. 64 | 65 | This project will also create a coafile bot. Users will be able to 'mention' the 66 | bot name in the issues section of their GitHub repositories, and then this bot 67 | will comment back with a coafile for their project. Additionaly it will also 68 | make a Pull Request with that coafile. The prototype can be found 69 | [here](https://github.com/hemangsk/gh-node-bot-prototype) and an example issue 70 | is [here](https://github.com/rahulcode22/Hackerrank/issues/6). 71 | 72 | #### Milestones 73 | 74 | ##### [PREPARATION/BONDING](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/3) 75 | 76 | * Decouple CSS from web projects and create unified library. 77 | * Make code coala compliant in landing-frontend, projects and webServices. 78 | * Add ```analytics``` endpoint in webServices to obtain bear click data. 79 | * Finalize enhanced UI mockups for coala Online and coala-html. 80 | 81 | ##### [CODING PHASE 1](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/7) 82 | 83 | * Add ```--dir``` and ```--sections_only``` option in coala-quickstart. 84 | * Add backend support for coala Online module on webServices. 85 | * Add backend support for GitHub repository linting on webServices. 86 | * Create frontend for coala Online by creating a JS library using directives 87 | from coala-html. 88 | 89 | ##### [CODING PHASE 2](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/8) 90 | 91 | * Add frontend support for GitHub repository linting on coala.io. 92 | * Implement a coafile bot. 93 | * Make projects repo easily configurable so that other orgs can use it. 94 | * Improve coala Online and GH linting UI based on user feedback. 95 | 96 | ##### [CODING PHASE 3](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/9) 97 | 98 | * Add CI on landing-frontend, projects and webServices. 99 | * Enhance coala-html UI and Add searching and filtering functionality. 100 | * Solve [coala-html#34](https://github.com/coala/coala-html/issues/34) and 101 | [coala-html#33](https://github.com/coala/coala-html/issues/33) 102 | * Revisit code in landing-frontend, projects and webServices and add tests. 103 | -------------------------------------------------------------------------------- /_projects/commit-based-perftest.md: -------------------------------------------------------------------------------- 1 | --- 2 | desc: "A technique to view the performance of a piece of software and 3 | automatically identify and classify performance drops and gains." 4 | developers_involved: [] 5 | difficulty: medium 6 | status: in_progress 7 | initiatives: 8 | - Paper 9 | issues: [] 10 | markdown: commit-based-perftest.md 11 | name: "Researching commit-based performance testing" 12 | requirements: 13 | - "The participant should have some prior experience with investigating the performance of software." 14 | tags: 15 | - Research 16 | - coala 17 | --- 18 | Imagine a `git blame` for performance. That is exactly what this project 19 | is about - identifying commits that are interesting from a performance 20 | point-of-view. 21 | 22 | In this project, we aim to research for techniques to classify performance 23 | changes across commits - find a correlation between the number of line 24 | additions/subtractions and the performance change, identify whether a new 25 | feature is really an optimization and so on. 26 | -------------------------------------------------------------------------------- /_projects/commit-content-checks.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Commit content inspection" 3 | desc: "Verification that the commit message accurately describes the patch" 4 | requirements: 5 | - "Merged pull requests to a vcs bear, e.g. GitCommitBear." 6 | difficulty: "low" 7 | issues: 8 | - "https://github.com/coala/coala-bears/issues/337" 9 | - "https://github.com/coala/coala-bears/issues/1976" 10 | - "https://github.com/coala/coala-bears/issues/1037" 11 | - "https://github.com/coala/coala-bears/issues/2409" 12 | - "https://github.com/coala/coala-bears/issues/1360" 13 | mentors: 14 | - damngamerz 15 | - guyzmo 16 | - latacz-io 17 | initiatives: 18 | - GSoC18 19 | status: completed 20 | tags: 21 | - CI 22 | collaborating_projects: 23 | - "coala" 24 | - "unidiff" 25 | --- 26 | 27 | There are many special types of commit messages that should be only used in conjunction with 28 | patches containing a special type of content. 29 | 30 | For example, `git revert` and `git merge` both generate a default commit message. 31 | 32 | The coala project does want to allow `git revert` commits, but does not want to accept 33 | `git merge` commits as our repositories are strictly fast-forward merges that do not 34 | have an extra commit. 35 | 36 | Both need to be detected, and allowed or disallowed based on configuration settings in 37 | `.coafile`. 38 | 39 | In addition there are special sequences that can be added to git commit messages to 40 | instruct tools to operate in a certain way. A common example is `[ci skip]` in 41 | the commit message denotes that the CI engines should not build the commit. 42 | Skipping CI is not usually desirable in coala commits, except in limited circumstances, 43 | so the decision to permit `[ci skip]` in a commit message requires inspection of the 44 | contents of the commit. 45 | 46 | coala already depends on `unidiff`, which can be used to load the commit patch for 47 | inspection. 48 | 49 | ## Git reverts 50 | 51 | A `git revert` has a generated commit message, and implies that the patch is a reversal of a 52 | previous patch which is explicitly mentioned in the commit message. 53 | 54 | However sometimes the changes in the commit are not an exact reversal of the patch which was reverted. 55 | This could be due to conflicts, or it might be a nefarious actor trying to introduce new code. 56 | 57 | When a `git revert` commit message is detected, the contents of the commit should be compared with the 58 | previously applied patch, and errors emitted based on configuration. 59 | 60 | One way to achieve this is to load the two patches, and verify they are inverse of each other. 61 | 62 | In the event that the patch is not identical, often an auxiallary note is required in the 63 | commit message to highlight it is not a clean revert. 64 | 65 | Also a similarity check is needed, as a minor difference in the patch might be acceptable, 66 | but an error is desired if there are significant changes compared with the previous patch. 67 | 68 | ## Git merge 69 | 70 | coala usually encounters git merges in Pull Requests due to GitHub rebases, which merge 71 | master onto the pull request. When this occurs, a custom message should explicitly 72 | inform the patch author how to rectify their PR. 73 | 74 | A special case is Travis CI builds, which are always a merge commit. These need to be 75 | handled carefully as a special case, so the bear skips past the special commit and 76 | instead inspects the top most commit as it appears on the Pull Request. 77 | 78 | #### Milestones 79 | 80 | ##### GSOC 2018 COMMUNITY/BONDING 81 | 82 | * Create a cEP describing the coala process rules which will be enforced by GitCommitBear. 83 | * Complete a work in progress of loading output of a git commit into `unidiff`. 84 | * The student has enabled GitCommitBear on a repository of their own, and 85 | has created example Pull Requests which show the various special commit types 86 | for `git revert` and `git merge`, and Travis builds. 87 | * The student has completed the newcomer process. 88 | 89 | ##### CODING PHASE 1 90 | 91 | * GitCommitBear support for Travis commits 92 | 93 | ##### CODING PHASE 2 94 | 95 | * GitCommitBear support of `git merge` commits 96 | 97 | ##### CODING PHASE 3 98 | 99 | * GitCommitBear support of `git revert` commits 100 | -------------------------------------------------------------------------------- /_projects/communication-bridge.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "A way to post CI problems to online team rooms, such as IRC, Telegram, slack or gitter." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC 8 | - RGSoC 9 | issues: [] 10 | markdown: communication-bridge.md 11 | mentors: 12 | - jayvdb 13 | - chauffer 14 | name: "Real-time team communication bridge" 15 | requirements: 16 | - "At least one patch to the coala core should be accepted and merged." 17 | - "Some familiarity with hubot" 18 | tags: 19 | - CI 20 | - Bots 21 | --- 22 | Sometimes a project integrates data from outside of the repository, so 23 | commit-based-CI alone isn't effective. New data could cause an error, which 24 | isn't noticed until the next code change is proposed, and the build breaks. 25 | Often a project will decide the build shouldn't break when the data is incorrect 26 | during regular development, and these validations are only enabled during betas 27 | and release candidates. 28 | 29 | To keep notifications about this errors occurring, regular builds with these 30 | checks enabled are necessary. These problems in imported data need to be 31 | distributed to the appropriate team somehow. 32 | 33 | A special CI build that fails is one option of notifying the team, but that 34 | isn't very informative, especially for teams that are not developers - they wont 35 | appreciate hunting down errors in CI logs. Ideally a steady stream of new 36 | problems are periodically posted to a online team room, such as IRC, Telegram, 37 | slack or gitter. 38 | 39 | One example is translations stored in a web service like Pootle. Translations 40 | in Pootle are not committed automatically. Also translations can become broken 41 | by development, so constant monitoring is needed. Translation teams typically 42 | hang out on a team chat service. 43 | 44 | The critical functionality is ensuring that the bot does not regularly repeat 45 | the same problem, unless configured to do so. It may take a while to find 46 | someone who knows how to fix the problem, or the number of problems may be too 47 | large to be regularly listed in the chat room. 48 | 49 | #### Milestones 50 | 51 | ##### PREPARATION/BONDING 52 | 53 | * The participant has merged an enhancement to cobot. 54 | 55 | ##### CODING PHASE 1 56 | 57 | * A system exists that posts notices into a chat room for every new error that 58 | occurs, without duplicating notices. 59 | 60 | ##### CODING PHASE 2 61 | 62 | 63 | ##### CODING PHASE 3 64 | 65 | * A system exists that engages contributors to pick up errors to be fixed. 66 | -------------------------------------------------------------------------------- /_projects/convert-bear-to-aspects.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "This project is about updating bear to use aspect feature." 5 | developers_involved: [] 6 | difficulty: medium 7 | initiatives: 8 | - GSoC18 9 | - RGSoC 10 | issues: [] 11 | markdown: convert-bear-to-aspects.md 12 | mentors: 13 | - adhikasp 14 | - jschwarzwalder 15 | - tadityar 16 | name: "Convert Bears to Aspects" 17 | requirements: 18 | - "The participant should have one patch to any bear accepted." 19 | - "The participant should have understanding of [cEP-0005](https://github.com/coala/cEPs/blob/master/cEP-0005.md)." 20 | - "The proposal should contain bears which are planned to be addressed and a 21 | rough draft on which aspects will be needed and how they will be 22 | implemented." 23 | status: completed 24 | tags: 25 | - Documentation 26 | - Bears 27 | - Aspects 28 | --- 29 | 30 | coala offers quite a number of bears to its users, many of them wrapping 31 | existing linters. 32 | Although coala offers benefits in usability by utilising a single configuration 33 | file and user interface, there is one last big obstacle left, from our point 34 | of view. 35 | Until now, developers have to know which tools offer a certain analysis. 36 | So if you for example want to have unused code detection for python, you have 37 | to find a tool like Vulture. 38 | Without coala you'd also have to learn how to use Vulture. But even coala does 39 | not help you with finding a tool that can detect unused code in python so far. 40 | 41 | This is where aspects do their work. 42 | We could say, an aspect is a kind of analysis we want to run over the code. 43 | For example, "UnusedCode" could be an aspect that describes analysis routines, 44 | that will detect code that is never reached. 45 | Now if a user wants to detect unused code, instead of stating which bear coala 46 | should use, which requires the user to know bears/tools and their options, 47 | they can simply add the "UnusedCode" aspect and coala will figure out what 48 | bears must be used and how to use them. 49 | 50 | The goal of this project is to create the aspects categories and annotate 51 | results of bears with them. The minimal expected result is coala/coala 52 | repository could be run with aspect-based setting (see 53 | for the suggested but non-complete 54 | bear list needed to accomplish this). This is what makes the aspects available 55 | to users and has to be built into each bear individually. 56 | 57 | References 58 | 59 | * Aspects concept based on 60 | [cEP-0005](https://github.com/coala/cEPs/blob/master/cEP-0005.md) 61 | * Proposal on how new bears could be designed 62 | [cEP-0002](https://github.com/coala/cEPs/blob/master/cEP-0002.md) 63 | * Current aspects prototype 64 | [coala/aspect-docs](https://github.com/coala/aspect-docs) 65 | 66 | #### Milestones 67 | 68 | ##### PREPARATION/BONDING 69 | 70 | * The list of planned migrated bears (at least 5) are drafted completely. 71 | * The names and settings of the needed aspects are drafted completely. 72 | 73 | ##### CODING PHASE 1 74 | 75 | * All of the drafted aspect are successfully merged and documented. 76 | 77 | ##### CODING PHASE 2 78 | 79 | * Improve existing helper function to make mapping setting to aspect setting 80 | easier. 81 | * Two thirds of the defined bears is annotated, could be executed under 82 | aspect config, and return results with aspects data. 83 | 84 | ##### CODING PHASE 3 85 | 86 | * All of the defined bears is annotated, could be executed under 87 | aspect config, and return results with aspects data. 88 | * Implement integration test, make sure the coala/coala repo could be run 89 | with aspect-based setting that similiar with current `.coafile` setting and 90 | return the same result set. 91 | -------------------------------------------------------------------------------- /_projects/corobo-enhancement.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Improve testing infrastructure, new plugins, improve labhub and security, better configurability" 5 | developers_involved: [] 6 | difficulty: medium 7 | initiatives: 8 | - GSoC18 9 | issues: 10 | - "https://github.com/coala/projects/issues/498" 11 | - "https://github.com/coala/corobo/issues/424" 12 | - "https://github.com/coala/corobo/issues/509" 13 | - "https://github.com/coala/corobo/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fconfig" 14 | markdown: corobo-enhancement.md 15 | mentors: 16 | - meetmangukiya 17 | - gbin 18 | - mixih 19 | name: "corobo enhancements(security, configurability and tests)" 20 | requirements: 21 | - "At least one patch to corobo should be accepted and merged." 22 | status: completed 23 | tags: 24 | - community 25 | - corobo 26 | --- 27 | 28 | Repository: https://github.com/coala/corobo 29 | 30 | corobo is a collection of [errbot](http://errbot.io) chatbot framework plugins. 31 | 32 | ### Better tests and testing infrastructure 33 | 34 | Some tests are really hacky involving manual instantiation of plugin classes, 35 | etc. The default TestBase provided by errbot was not enough for testing plugins 36 | like LabHub, which required intensive mocking. 37 | 38 | One can analyze the current tests and see what bits are missing in the TestBase 39 | provided by errbot, and try to implement it, such that it'd be accepted and 40 | merged upstream. 41 | 42 | ### Improving labhub and security 43 | 44 | Security has been one of major concerns due to some recent events. We want to 45 | provide access controls based on user's GitHub team memberships. The ACL plugin 46 | provided by errbot can be reused for this. Ideally, one should make the ACL 47 | plugin extensible, allowing custom access control functions, etc. and then 48 | extend it for coala specific needs. 49 | 50 | ### Better configurability 51 | 52 | corobo has a potential to be used by other organizations for similar tasks as 53 | well. For onboarding and automation. Major hurdle in this would be 54 | configurability. Currently, corobo is not configurable and many plugins are 55 | still very coala specific. The end goal would be to have easy configuration of 56 | corobo to allow other orgs to adapt corobo to cater their needs. 57 | -------------------------------------------------------------------------------- /_projects/create-jenkins-plugin.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - jenkins 5 | desc: "Jenkins users should be able to see coala results right in the Jenkins UI." 6 | difficulty: low 7 | status: disabled 8 | initiatives: 9 | - GSoC 10 | - RGSoC 11 | issues: 12 | - "https://github.com/coala/coala/issues/2757" 13 | markdown: create-jenkins-plugin.md 14 | mentors: 15 | - Udayan12167 16 | - uhafner 17 | name: "Create Jenkins Plugin" 18 | requirements: 19 | - "Any patch to jenkins has been accepted." 20 | - "The applicant is familiar with the coala plugins." 21 | - "Any patch to any coala plugin has been accepted and merged." 22 | tags: 23 | - Plugins 24 | - CI 25 | --- 26 | 27 | **Disabled: This project is not available for GSOC 2018. See Jenkin's GSOC 28 | [page](https://summerofcode.withgoogle.com/organizations/5572716199936000/) 29 | if you are interested in working with them** 30 | 31 | Jenkins is the most popular ci-cd server, and there are many corporations 32 | who already use it. Integrating coala into Jenkins can attract business 33 | clients better who could end up sponsoring/helping out coala. 34 | It also generally allows a wider range of users to use coala 35 | in their preferred way. 36 | 37 | The goal of this project is to offer a coala plugin for Jenkins to 38 | allow easy integration of coala. The users should benefit from coala 39 | without additional manual work and get the result clearly in Jenkins. 40 | 41 | [Writing a coala Jenkins Plugin - Google Groups](https://groups.google.com/forum/#!msg/jenkinsci-dev/2LciAQgdRcY/Kv2rQlwXAAAJ) 42 | could help you to build the plugin. 43 | There is a similiar plugin in Jenkins plugin repository, 44 | [warnings plugin](https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin). 45 | It can parse the output and present warnings and errors in JenkinsUI. 46 | A parser for warnings plugin could be implemented in the early stage 47 | of developing. It's easy to get started. 48 | 49 | #### Milestones 50 | 51 | ##### PREPARATION/BONDING 52 | 53 | * A test jenkins instance exists. 54 | * An official repository exists with CI. 55 | 56 | ##### CODING PHASE 1 57 | 58 | * A parser exists for parsing coala result. 59 | 60 | ##### CODING PHASE 2 61 | 62 | * A working plugin with minimal functionality exists. 63 | * Corresponding testsuite exists. 64 | * Corresponding documentation exists. 65 | 66 | The testsuite and documentation should be exhaustive and complete. 67 | As the plugin is just rudimentary, the testsuite and documentation also 68 | are simple at this stage. 69 | 70 | ##### CODING PHASE 3 71 | 72 | * A working plugin with full functionality exists. 73 | * A full covering testsuite exists. 74 | * Full Documentation exists. 75 | -------------------------------------------------------------------------------- /_projects/debug-profile.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "coala should support developers of code analysis by providing facilities to debug and profile bears." 5 | difficulty: high 6 | initiatives: 7 | - GSoC18 8 | - RGSoC 9 | issues: 10 | - "https://github.com/coala/coala/issues/565" 11 | - "https://github.com/coala/coala/issues/1101" 12 | markdown: debug-profile.md 13 | mentors: 14 | - fneu 15 | - arjunsinghy96 16 | - Makman2 17 | name: "Debug and Profile Bears" 18 | requirements: 19 | - "At least one patch to the coala core should be accepted and merged." 20 | - "The student should be familiar with ongoing technical [cEPs](https://coala.io/cep)." 21 | - "The proposal needs to contain a clear concept." 22 | - "Familiarity with pdb is a plus." 23 | status: completed 24 | tags: 25 | - Core 26 | - Bears 27 | - Debugging 28 | --- 29 | 30 | A famous programming quote reads "Debugging is twice as hard as writing code 31 | in the first place". Thus even though writing code can be as trivial as 32 | opening up your favorite text editor and crunching some keys we need tools to 33 | help us debug our code. An essential toolset that coala lacks is the ability 34 | to debug its Bears, i.e. the analysis procedures. In the development lifecycle 35 | of a Bear it needs to be debugged and profiled and coala should provide a 36 | comprehensive environment for this. 37 | 38 | In this project the participant shall develop a system to easily 39 | step into the analysis code (likely using the Pdb module already integrated 40 | into Python) and step out as soon as the analysis finished. The following are 41 | desirable goals for such a toolset's features: 42 | 43 | 1. The ability to jump directly into Bear code and move through it using a 44 | debugger interface such as pdb. 45 | 2. The toolset should also provide the ability to invesitgate the settings 46 | passed to the Bear. 47 | 3. Inspect the results created by the Bear. 48 | 49 | This rich source of information allows Bear developers to create better 50 | performant Bears through the profiling interface. It also makes Bear 51 | developement easier through the debugging interface. Also, it gives the added 52 | benefit of better quality Bears being contributed to the community. 53 | 54 | #### Milestones 55 | 56 | ##### PREPARATION/BONDING 57 | 58 | * The applicant has gone through the [pdb documentation](https://docs.python.org/3.4/library/pdb.html). 59 | * The applicant has made a [cEP](https://coala.io/cep) of how the profiling 60 | will be implemented has been merged. 61 | 62 | ##### CODING PHASE 1 63 | 64 | * Pdb should be integrated completely into the coala core. 65 | * Documentation and tests for the above task are completed. 66 | 67 | ##### CODING PHASE 2 68 | 69 | * Settings of Bears can be accessed in the debug environment. 70 | * Documentation and tests for the above task are completed. 71 | * The profile option is added to CLI. 72 | 73 | ##### CODING PHASE 3 74 | 75 | * The ability to inspect results produced by the bears is implemented. 76 | * The documentation about profiling is written. 77 | * A demo of how to use the profiling and debuggin is included in the 78 | documentation. 79 | -------------------------------------------------------------------------------- /_projects/django-microfarm.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - WeField 4 | - Hofly. 5 | - coala 6 | desc: "Make sustainable farming available for everyone." 7 | developers_involved: [] 8 | difficulty: medium 9 | initiatives: 10 | - GSoC 11 | markdown: django-microfarm.md 12 | mentors: 13 | - Finn-1 14 | - sils 15 | - JuliaRahn 16 | name: "django-microfarm" 17 | tags: 18 | - WeField 19 | - django 20 | --- 21 | 22 | WeField e.V. is an german NGO that takes regenerative and climate actions on 23 | monocultural used / Wasteland. 24 | 25 | One of our project fields is a pilot for a self sufficient microfarm in a 26 | regenerative design. The aim of this project is to create a tool that allows 27 | anyone to become a market gardener, given some space. 28 | 29 | As a first step, a user will merely sign up and enter the amount of space that 30 | (s)he wants to use. The system will then trigger tasks the user has to do in 31 | order to efficiently farm on his space. Those tasks are triggered by simple 32 | rules and may depend on weather events, date and later also other triggers. 33 | 34 | The aim of this project is to build a django project that is interfaced via 35 | the autogenerated django-admin. A proper frontend can be built later and is an 36 | optional goal of this project. 37 | 38 | #### Getting Started 39 | 40 | If you are interested in working on this project, contact 41 | via email. 42 | 43 | #### Milestones 44 | 45 | ##### BONDING 46 | 47 | * Do a virtual farm tour and 2 workshops on market garden and farm 48 | organisation with Finn/Julia 49 | * Define task triggers and database layouts with Finn/Julia 50 | * Decide on weather API 51 | * Decide on how to put rule logic into the database 52 | 53 | ##### CODING PHASE 1 54 | 55 | * Create a basic django project on a new GitLab project 56 | * Set up CI for tests 57 | * Set up deployment 58 | * Implement user system and login 59 | * Implement weather API 60 | * Implement daily chore tasks 61 | * Implement mail notifications 62 | 63 | ##### CODING PHASE 2 64 | 65 | * Implement watering tasks 66 | * Implement unit tests for all important tasks 67 | * Create django admin view and filters for tasks for a specific user 68 | * (Optional) Create a frontend app for users to use on mobile 69 | -------------------------------------------------------------------------------- /_projects/documentation-extraction.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "The Project is about writing language independent documentation extraction and parsing algorithms." 5 | developers_involved: [] 6 | difficulty: high 7 | status: completed 8 | initiatives: 9 | - GSoC17 10 | - RGSoC 11 | issues: [] 12 | markdown: documentation-extraction.md 13 | mentors: 14 | - SanketDG 15 | name: "Documentation Extraction and Parsing" 16 | requirements: 17 | - "The participant should have one bugfix patch to any bear accepted." 18 | - "The participant should have a basic understanding of the algorithms behind 19 | existing documentation extraction routines." 20 | tags: 21 | - Documentation 22 | - Bears 23 | --- 24 | 25 | Code needs documentation. Everyone knows that, but for some reason it doesn't 26 | end up having one. 27 | 28 | This probably is partly due to the fact that having a second place to write 29 | documentation makes it easy to "forget" about it. To solve this problem, and 30 | also to offer developers easier access to some important information, many 31 | languages support having documentation in source files. The problem with this 32 | is, that most linters only work on code or pure documentation files but can not 33 | lint documentation in source files. This leads to a lack of checks for in 34 | source documentation which then can lead to bad documentation due to formatting 35 | issues and the like. While the programmer writes the documentation, coala could 36 | help the programmer conform to the documentation standard and other trivial 37 | issues such as capitalization and grammar. 38 | 39 | For python, its [docstrings](https://www.python.org/dev/peps/pep-0257/) 40 | 41 | The aim of the project is to develop an analyzing routine at least for python and java 42 | that will find all documentation strings in a file, parse them into specific 43 | groups and check them against a specified documentation style given by the 44 | user. The functionality can be extended so that the analyzing routine provides 45 | a patch that re-formats the documentation correctly, check for grammatical 46 | errors and perform other aesthetical fixes. 47 | 48 | 49 | #### Milestones 50 | 51 | ##### PREPARATION/BONDING 52 | 53 | * Investigate about docstring diff's cut-off bug. 54 | Related: [#4187](https://github.com/coala/coala/issues/4187) 55 | * Fix `allow_missing_func_desc` in current implementation of DocStyleBear. 56 | * Investigate about existing DocStyleBear. (Check if DocStyleBear runs fine on coala and coala-bears repo) 57 | * Investigate about coala's project structure. (Write a blog introducing the same to the community) 58 | 59 | ##### CODING PHASE 1 60 | 61 | * Fix DocumentationExtraction related issues. 62 | Related: [#18](https://gitlab.com/coala/GSoC/GSoC-2017/issues/18) 63 | * Fix DocumentationComment related issues. 64 | Related: [#19](https://gitlab.com/coala/GSoC/GSoC-2017/issues/19) 65 | 66 | ##### CODING PHASE 2 67 | 68 | * Rigorous testing of newly renovated DocumentationAPI, with the use of existing DocStyleBear. 69 | * A `DocBaseClass`, which does extraction, parsing and diff generation, is implemented. 70 | Related: [#2659](https://github.com/coala/coala/issues/2659) 71 | * DocStyleBear at least for python and java, which uses `DocBaseClass`, is implemented. 72 | 73 | ##### CODING PHASE 3 74 | 75 | * DocGrammarBear at least for python and java, which uses `DocBaseClass`, is implemented. 76 | * Investigate newly formed DocStyleBear and DocGrammarBear by running them on real projects. 77 | * Improve/Fix bugs, quirks, unit-testing, improvements over test cases and documentation. 78 | -------------------------------------------------------------------------------- /_projects/editor-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Develop an efficient strategy that allows coala to maintain a number of plugins for different editors." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC19 8 | - RGSoC 9 | issues: 10 | - "https://github.com/coala/coala-atom/issues/37" 11 | - "https://github.com/coala/coala-emacs/issues/11" 12 | - "https://github.com/coala/coala-eclipse/issues/25" 13 | - "https://github.com/coala/coala-vim/issues/24" 14 | - "https://github.com/coala/coala-gedit/issues/5" 15 | - "https://github.com/coala/coala-sublime/issues/4" 16 | markdown: editor-support.md 17 | mentors: 18 | - AbdealiJK 19 | - fneu 20 | name: "Cohesive Editor Support" 21 | status: completed 22 | requirements: 23 | - "The proposal has to provide a convincing strategy for testing, documentation and maintaining editor plugins" 24 | - "The applicant should have one patch accepted to any of the coala plugins." 25 | tags: 26 | - Editors 27 | - Plugins 28 | --- 29 | coala features quite a few editor plugins already, none of which are 30 | *supported* by the definition of having regular continuous integration and 31 | tests running to ensure its functionality. The goal of this project is to 32 | plan, introduce and configure a testing routine that allows coala to ensure 33 | the functioning of its editor plugins at all times. Presently, the lack of a 34 | proper testing environment leads to the breakdowns of plugins going unnoticed. 35 | A viable approach might be to set up weekly tests for the current editor 36 | plugins. 37 | 38 | The goal is to develop an efficient strategy that allows coala to maintain a 39 | number of plugins for different editors. This would not only benefit coala by 40 | attracting more developers as the plugins across various platforms will be 41 | widely used, but it would also benefit the end-users by giving them a working 42 | linter plugin across their favourite editors which are easily maintained and 43 | tested regularly with the latest build of coala. 44 | 45 | For sublime, we'll be using the 46 | [unittest plugin](https://github.com/randy3k/UnitTesting) 47 | which is a plugin by itself. 48 | For atom, we have the apm testing architecture 49 | which does not require a GUI. 50 | For VI and emacs, we will most likely use a testing framework such as 51 | [Vimcasts](https://github.com/kana/vim-vspec). 52 | For some editors like gedit, running tests is not easy and 53 | there is no api to do it. In such cases we would want to use 54 | [dogtail](https://fedorahosted.org/dogtail/) 55 | (a GUI tester) or a similar tool to do this. 56 | 57 | We will have to explore the possibility of having a single git repository for 58 | atom, sublime-text and vim as it will ultimately be easier to maintain in the 59 | long run and will have a proper CI, which can be easily managed. Issues will 60 | be raised more frequently as a result of this. 61 | 62 | Documentation which isn't available at the moment will have to describe the 63 | usage details of existing plugins, we can have asciicinemas or gifs of the 64 | entire process from installation to examples of the plugins in action. 65 | Documentation can also be created for future plugins, and on the basis of the 66 | tests which will be written for the existing ones, it'll be easier to test 67 | the future plugins. This will result in a clear cut path of creating plugins 68 | for coala. 69 | 70 | 71 | #### MILESTONES 72 | 73 | ##### PREPARATION/BONDING 74 | 75 | * A cEP for the testing, documentation and maintaining strategy has been merged. 76 | 77 | ##### CODING PHASE 1 78 | 79 | * The testing strategy has been set up for coala. 80 | * At least one of coala's editor plugins is continually tested. 81 | 82 | ##### CODING PHASE 2 83 | 84 | * Documentation and tutorials showing the usage of existing plugins is 85 | available. 86 | * Maintaining strategy is placed into effect. 87 | 88 | ##### CODING PHASE 3 89 | 90 | * At least three of coala's editor plugins are continually tested. 91 | * Documentation is available to easily set up testing for future editor plugins. 92 | -------------------------------------------------------------------------------- /_projects/enhance-coala-quickstart.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Extract useful data from a project's configuration files to build a relevant `.coafile`." 5 | developers_involved: [] 6 | difficulty: medium 7 | status: completed 8 | initiatives: 9 | - GSoC17 10 | - RGSoC 11 | issues: 12 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/21" 13 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/56" 14 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/58" 15 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/59" 16 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/150" 17 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/60" 18 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/61" 19 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/62" 20 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/63" 21 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/64" 22 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/65" 23 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/66" 24 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/67" 25 | markdown: enhance-coala-quickstart.md 26 | mentors: 27 | - adtac 28 | - Adrianzatreanu 29 | name: "Enhance coala-quickstart" 30 | requirements: 31 | - "At least one patch to coala core and coala-quickstart each should be accepted and merged." 32 | - "The student should be familiar with ongoing technical [cEPs](https://coala.io/cep)." 33 | tags: 34 | - "Information Extraction" 35 | - CLI 36 | - CI 37 | --- 38 | [coala-quickstart](https://github.com/coala/coala-quickstart) is a tool that 39 | helps users to quickly get started with coala. It generates a `.coafile` 40 | (coala's configuration file) that is tailored to the project. Currently, 41 | coala-quickstart automatically identifies relevant bears for the project 42 | based on the languages used and has a clean and simple command-line interface 43 | for taking user’s input when required. 44 | 45 | However, there’s scope for improvement in the following areas: 46 | 47 | - Utilizing information from common configuration files: Some projects have 48 | configuration files like `Gruntfile.js`, `Gulpfile.js`, `rakefile`, 49 | `package.json`, etc., which may contain useful data that's relevant to 50 | coala-quickstart. For example, if a project's Gulpfile.js specifies which 51 | files are to be linted with csslint, we could use this information to target 52 | CSSLintBear at exactly these files. 53 | - Improving the interface: 54 | - Removing non user-friendly warnings. 55 | - Increasing automation. 56 | - Validate user input before writing to the generated coafile. 57 | - Continuous Integration: Like other coala repositories, add Appveyor 58 | (Windows) and Travis (OSX) integartions. 59 | 60 | 61 | #### Milestones 62 | 63 | ##### [PREPARATION/BONDING](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/6) 4th May - 29th May 64 | * [X] Identified all the kinds of configuration files to be worked 65 | on in the project. 66 | * [X] Figure out all the useful information that could be 67 | extracted from these files. 68 | * [X] Get the cEP https://github.com/coala/cEPs/issues/80 merged. 69 | 70 | ##### [CODING PHASE 1: Extracting Information](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/20) 30th May - 26th June 71 | 72 | * [ ] The basic structure of the information extraction system is implemented. 73 | * [ ] Extract information from `Gruntfile.js`, `package.json` and `Gemfile`. 74 | 75 | ##### [CODING PHASE 2: Utilizing the Information](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/21) 30th June - 24th July 76 | 77 | * [ ] CLI: Add autocomplete feature, add prompts for "detect" and "fix" capabilities. 78 | * [ ] Collect and organize bears' metadata. 79 | * [ ] Filter and recommend bears after utilizing extracted information. 80 | 81 | ##### [CODING PHASE 3: CLI enhancements](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/22) 28th July - 21st August 82 | 83 | * [ ] Validate user input. 84 | * [ ] Fix warning and formattings on the CLI. 85 | * [ ] Continuous Integration. 86 | * [ ] Complete Pending tasks (if any). 87 | 88 | ##### [Stretch Goals](https://gitlab.com/coala/GSoC/GSoC-2017/milestones/4) 89 | 90 | * [ ] Implement `.editorconfig` parser and extract information from `.editorconfig` 91 | * [ ] Extract information from other meta-files. 92 | * [ ] Smart update of generated `.coafile` w.r.t. changes in meta-files. 93 | * [ ] Installing required bear-dependencies using cib. 94 | -------------------------------------------------------------------------------- /_projects/example.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Write Project Name Here" 3 | desc: "Write a one line Description of Project here." 4 | requirements: 5 | - "The applicant has to fulfill this to get started." 6 | difficulty: "low|medium|high" 7 | issues: 8 | - "https://github.com/coala/coala/issues/####" 9 | mentors: 10 | - sils 11 | - sims1253 12 | initiatives: 13 | - GSoC 14 | tags: 15 | - Plugins 16 | - CI 17 | collaborating_projects: 18 | - "Add umbrella and sub-orgs here" 19 | --- 20 | 21 | This space is for the main description. Use it wisely. 22 | 23 | #### Milestones 24 | 25 | ##### PREPARATION/BONDING 26 | 27 | * Conceptual work should be finished. 28 | * The student should have a repository, know how to work with the community. 29 | * The applicant should know the community. 30 | 31 | ##### CODING PHASE 1 32 | 33 | * Everything listed here has to be reviewed and merged. 34 | * No exceptions to that. Changing the goals is possible together with mentors. 35 | * Yes, that includes tests and documentation. 36 | 37 | ##### CODING PHASE 2 38 | 39 | * Most of the coding work must be finished. 40 | 41 | ##### CODING PHASE 3 42 | 43 | * Everything has to be reviewed and merged. 44 | * Including tests and docs, again. 45 | -------------------------------------------------------------------------------- /_projects/generic-bears.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "The project is about fixing Issues with Generic Bears and providing better API." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC19 8 | - RGSoC 9 | issues: [] 10 | markdown: generic-bears.md 11 | mentors: 12 | - abhishalya 13 | - sangamcse 14 | name: "Improve Generic Bear Quality" 15 | requirements: 16 | - "The participant should have one bugfix patch to any bear accepted." 17 | - "The participant should have an understanding of the algorithms behind 18 | existing Generic bears and test framework for bears." 19 | - "The proposal should contain issues which are planned to be addressed, 20 | chosen (and potentially 21 | [filed](https://github.com/coala/coala-bears/issues/new)) by the student." 22 | status: completed 23 | tags: 24 | - Documentation 25 | - Bears 26 | - Testing 27 | --- 28 | 29 | Generic Bears have the potential to be awesome. 30 | They provide language agnostic analysis algorithms like checking if you use the 31 | preferred quotes in your file. 32 | They have started to get there, but are not as reliable and feature complete as 33 | we'd love them to be. 34 | 35 | This project touches the most important, but often overlooked, work in open 36 | source projects. Maintenance. 37 | These new and cool bears were merged in euphoria as they were... well new and 38 | cool. 39 | But as with all code, they contain bugs and sometimes cases were missed and so 40 | they now lie there, waiting to be looked at again, while the euphoric hordes 41 | moved on, to the next new and cool feature. 42 | Imagine WALL·E and the whole coala project being the earth. 43 | (It is not as bad as in the movie, we promise!) 44 | There are some WALL·Es out there, trying to fix the most important bugs and 45 | errors, but there simply aren't enough as most developers have more in common 46 | with the humans in that movie. 47 | 48 | This project is about getting the once new and cool features into a state, that 49 | makes them useful in production. 50 | Until then, they are mere prototypes to feed the everlasting hunger of new and 51 | cool things. 52 | These bears can be found 53 | [here](https://github.com/coala/coala-bears/tree/master/bears/general). Issues 54 | related to generic bears can be found 55 | [here](https://github.com/coala/coala-bears/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Aarea%2Fgenericbears%20). 56 | 57 | The task is to fix as many issues with these bears and make them as usable 58 | as possible. 59 | 60 | #### Milestones 61 | 62 | ##### PREPARATION/BONDING 63 | 64 | * The Student has identified at least 10 important issues 65 | (barring newcomer difficulty) that need to be solved. 66 | * All issues are discussed, and a general idea behind the algorithm of 67 | most generic bears is developed. 68 | * New changes to these algorithms (if required) are proposed. 69 | 70 | ##### CODING PHASE 1 71 | 72 | * The student has developed an idea to implement at least 1 proposed Generic 73 | Bear (either by the community or the student). 74 | * The student has discussed an initial algorithm behind the proposed Bear. 75 | 76 | ##### CODING PHASE 2 77 | 78 | * Half of the issues defined in the proposal are resolved. 79 | * The bare-bones version of the proposed Bear is implemented, tested and 80 | documented. 81 | 82 | ##### CODING PHASE 3 83 | 84 | * A given set of issues defined in the proposal are resolved. 85 | * The proposed Bear is fully implemented, tested and documented. 86 | -------------------------------------------------------------------------------- /_projects/git-bug.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "git-bug" 3 | desc: "Improve git-bug" 4 | requirements: 5 | - "The student should have compiled and started using git-bug." 6 | - "The student should have worked on a small feature/improvement/bugfix 7 | for git-bug." 8 | difficulty: "medium" 9 | issues: 10 | - "https://github.com/coala/projects/issues/648" 11 | mentors: 12 | - MichaelMure 13 | initiatives: 14 | - GSoC19 15 | status: completed 16 | tags: 17 | - git 18 | - bugtracker 19 | - github 20 | collaborating_projects: 21 | - coala 22 | --- 23 | 24 | git-bug is a distributed bug-tracker embedded in git. It allows contributor 25 | to a project to browse, edit and collaborate on issues, including offline, 26 | with no more than the normal git remote repository that you are already using 27 | for the source code of your project. 28 | 29 | git-bug provide a set of command line tools, an interactive terminal UI and a 30 | rich web UI. git-bug also currently provide a Github incremental importer to 31 | interact with regular bug trackers. 32 | 33 | Multiple projects are possible: 34 | - a Github exporter (https://github.com/MichaelMure/git-bug/issues/56) 35 | - an importer/exporter for Gitlab / Launchpad / your favorite bug tracker 36 | - improving the webUI to make it matche the features of the terminal UI 37 | - adding more features in git-bug in general 38 | (see https://github.com/MichaelMure/git-bug/issues) 39 | - any project you would like to take care of ;-) 40 | -------------------------------------------------------------------------------- /_projects/git-bug2.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Improve git-bug" 5 | developers_involved: [] 6 | difficulty: hard 7 | initiatives: 8 | - GSoC 9 | markdown: git-bug2.md 10 | mentors: 11 | - MichaelMure 12 | name: "git-bug" 13 | tags: 14 | - git 15 | - bugtracker 16 | - github 17 | --- 18 | 19 | [git-bug](https://github.com/MichaelMure/git-bug) is a distributed 20 | bug-tracker embedded in git. It allows contributor to a project to browse, 21 | edit and collaborate on issues, including offline, with no more than the 22 | normal git remote repository that you are already using for the source 23 | code of your project. 24 | 25 | git-bug provide a set of command line tools, an interactive terminal UI and a 26 | rich web UI. git-bug also provide bridges with external bugtracker like Github, 27 | Gitlab or Jira. 28 | 29 | Multiple projects are possible: 30 | - implementing support for pull-requests 31 | - improving various components (bridges, webui, termui ...) 32 | -------------------------------------------------------------------------------- /_projects/git-task-list.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - gsoc-prep-tasks 4 | desc: "List open issues and pull request from various issue tracker of a specified organization." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC 8 | issues: 9 | - https://github.com/coala/coala/issues/4080 10 | markdown: git-task-list.md 11 | mentors: 12 | - blazeu 13 | - yukiisbored 14 | - yashovardhanagrawal 15 | name: "Git Task List" 16 | requirements: 17 | - "The applicant should have at least one patch merged to any of the coala repositories." 18 | - "Familiarity with Git, GitHub API, Phabricator API, and GitLab API" 19 | - "Familiarity with EmberJS and GitHub Pages" 20 | status: 21 | - in_progress 22 | - disabled 23 | tags: 24 | - community 25 | - web 26 | --- 27 | The basic idea is an extended version of [GSOC Task List](https://github.com/summerofcode/gsoc-prep-tasks). 28 | 29 | In this project, tasks means open issues and unmerged pull request coming from 30 | GSOC open source projects. 31 | 32 | [GSOC prep task](https://coala.github.io/git-task-list/) is an issue 33 | finding tools that is (currently) integrated only with GitHub. It helps filter 34 | out the GitHub issues and only show the issues that are newcomer friendly and 35 | coming from limited GSoC organization. It limits the organization because 36 | different organization use different kind of issue tracking such as Phabricator 37 | and GitLab. 38 | 39 | **Git Task List** is conceptually the same as [GSOC prep task](https://coala.github.io/git-task-list/). 40 | Git Task List target a broader task type which include pull request review as 41 | the task. The goal of this project is to help developer to keep contributing to 42 | open source project by providing a sets of tasks that has been filtered using 43 | predefined keywords. 44 | 45 | In coala, this project will help sharing the tasks of reviewing a pull request 46 | on a project accross GitHub and GitLab. It will help fix the problem where 47 | developer spend too much time finding PR that haven’t been reviewed. This 48 | projects aims to getting more developer doing reviews works and sharing reviews 49 | workload, by providing an easy way to find issues that has not been reviewed 50 | both on http://github.com/coala and http://gitlab.com/coala. 51 | 52 | This will also help engage the developer to keep contributing to a project where 53 | they can’t find any issue that they can fix or keep the newcomer issue for new 54 | comer as learning path and developer with more experience can contribute by 55 | reviewing newcomer’s work PR. 56 | 57 | The goal of this projects is a static-site web page where the user 58 | can find Issues and Pull Request that haven’t been reviewed. User can select 59 | projects in Open Source hosting services like GitHub or GitLab. They also have 60 | the ability to select prefered programming language, tags, owner of the pull 61 | requests, and other metadata that is provided by the web services 62 | (GitHub/GitLab). 63 | 64 | Because the concept of this project, is the same as [GSOC prep task](https://coala.github.io/git-task-list/) 65 | , it can be used as the starting point of this project. 66 | 67 | #### Known Issue Tracker Usage In GSOC Organization 68 | 69 | Issue Tracker | Usage 70 | --- | --- 71 | GitHub | 16 72 | Trac | 7 73 | Atlassian Jira | 7 74 | GitLab | 4 75 | phabricator | 4 76 | BugZilla | 4 77 | Usabilla | 2 78 | Redmine | 2 79 | 80 | Because of the difficulty to support all of the known issue tracker in the range 81 | of GSOC timeline. This project will provide support for GitHub, GitLab, and 82 | Phabricator. 83 | 84 | #### Identifying Task Of A Specific Organization 85 | 86 | For a hosted issue tracker (like GitHub.com & GitLab.com) it is already 87 | documented and we can confidently know what resource are posible and what is not 88 | . The process of adding support for a new organization is posible using an 89 | external data source such as [Wikidata](http://wikidata.org). The app can fetch 90 | for list of organization that use GitHub / GitLab via [Qikidata Query API](https://query.wikidata.org/) 91 | 92 | The case is different for a self hosted Organization. The accessibility is 93 | different. For organization that use Phabricator as issue tracker, the process 94 | of adding support to it will be manually for each organization to make sure that 95 | the API is accessible. 96 | 97 | #### Milestone 98 | 99 | ##### Phase 1 100 | - Use GraphQL (GitHub). 101 | - Add support to all GSOC 2018 organizations that are using GitHub as an issue 102 | tracker. 103 | - Add GitLab.com support. 104 | - Search issues from a specified project. 105 | 106 | ##### Phase 2 107 | - GitHub & GitLab. 108 | - Search open MR/PR. 109 | - Browse MR/PR by authors. 110 | - Add support to list Issues and MR from http://gitlab.com/coala. 111 | - Add support to all GSOC 2018 organizations that are using GitLab.com as an 112 | issue tracker. 113 | 114 | ##### Phase 3 115 | - Browse PR by authors. ([coala/git-task-list#20](https://github.com/coala/git-task-list/issues/20)) 116 | - Add support GitLab CE. 117 | - Add Phabricator support. 118 | - Add support to some GSOC 2018 organizations that are using Phabricator and 119 | opened their api for public use. 120 | -------------------------------------------------------------------------------- /_projects/gitmate-coala.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Imrpove Gitmate integration for coala for better project maintenance" 5 | developers_involved: [] 6 | difficulty: medium 7 | initiatives: 8 | - GSoC 9 | markdown: gitmate-coala.md 10 | mentors: 11 | - abhishalya 12 | - sils 13 | name: "Gitmate for coala" 14 | tags: 15 | - gitmate 16 | --- 17 | 18 | [Gitmate](https://gitlab.com/gitmate) is one of the most 19 | integrated git solution at coala. Unfortunately, the project was 20 | then left unmaintained and hence needs a revamp. Gitmate helps 21 | coala in handling some of the crucial workflows responsible for 22 | a smooth development experience for the newcomers in open-source 23 | community. 24 | 25 | As a part of the project we will be integrating gitmate with coala 26 | and will be maintaing the project here. IGitt is the package powering 27 | the Git workflow for Gitmate. This project will require several 28 | improvements to IGitt as well to ensure Gitmate works well with the 29 | latest API versions for Github, Gitlab and Jira. 30 | 31 | Due to recent changes in GSoC with the program being only for 10 weeks 32 | the coding phases below are adjusted accordingly. 33 | 34 | #### Milestones 35 | 36 | ##### COMMUNITY BONDING 37 | 38 | * Student should have a clear plan and conceptual work must be finished. 39 | * The applicant should know how to work with the community. 40 | 41 | ##### CODING PHASE 1 42 | 43 | * Changes to the IGitt must be finished including writing tests and 44 | documentation. 45 | 46 | ##### CODING PHASE 2 47 | 48 | * Gitmate should have a proper integration with the latest API versions of 49 | Github, Gitlab and Jira. 50 | * Refactoring of the existing CI/CD setup for Gitmate. 51 | -------------------------------------------------------------------------------- /_projects/gitmate-jira.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - GitMate 5 | - IGitt 6 | desc: "GitMate.io helps by automating tasks on GitHub and GitLab. It's time to add Jira!" 7 | developers_involved: [] 8 | difficulty: medium 9 | initiatives: 10 | - GSoC17 11 | - RGSoC 12 | issues: 13 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/6" 14 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/26" 15 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/27" 16 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/7" 17 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/24" 18 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/79" 19 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/83" 20 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/84" 21 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/85" 22 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/86" 23 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/87" 24 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/88" 25 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/89" 26 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/90" 27 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/91" 28 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/92" 29 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/93" 30 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/94" 31 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/95" 32 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/96" 33 | - "https://gitlab.com/coala/GSoC/GSoC-2017/issues/97" 34 | markdown: gitmate_jira.md 35 | mentors: 36 | - nkprince007 37 | - sils 38 | - fneu 39 | name: "Implement Jira Support for GitMate" 40 | requirements: 41 | - "The participant should have at least one patch to 42 | [IGitt](https://gitlab.com/gitmate/open-source/IGitt/) accepted." 43 | - "The participant should have at least one patch to 44 | [GitMate](https://gitlab.com/gitmate/open-source/gitmate-2) accepted." 45 | - "The participant should demonstrate that he can operate Jira from the Python shell in his proposal." 46 | status: disabled 47 | tags: 48 | - IGitt 49 | - Jira 50 | --- 51 | 52 | [GitMate.io](https://gitmate.io/) is an automation tool for developers and it lacks 53 | [Jira](https://www.atlassian.com/software/jira) support. 54 | Many open source projects and companies use Jira. 55 | 56 | For more information about Jira and their REST API, you can look at 57 | [an existing Python implementation](https://github.com/pycontribs/jira#jira-python-library). 58 | 59 | This project involves adding a Jira implementation to [IGitt](https://gitlab.com/gitmate/open-source/IGitt/) 60 | as well as using that within [GitMate.io](https://gitmate.io/) (i.e. add webhooks and "signup with jira"). 61 | 62 | We look forward to hearing about your approach to making this happen. If you 63 | want, you can define optional goals which could be little snippets of 64 | automation targeted to Jira users. 65 | (See also [our documentation about creating plugins](http://docs.gitmate.io/Developers/Writing_Plugin/).) 66 | 67 | Please ask us for a Jira license to play around with at any time. 68 | 69 | See also last year's project which was about adding GitLab: 70 | 71 | - https://gitlab.com/coala/GSoC/GSoC-2017/milestones/1 72 | - https://gitlab.com/coala/GSoC/GSoC-2017/milestones/30 73 | - https://gitlab.com/coala/GSoC/GSoC-2017/milestones/31 74 | - https://gitlab.com/coala/GSoC/GSoC-2017/milestones/32 75 | 76 | To get started on GitMate, please follow [our guide](http://docs.gitmate.io/Developers/Newcomers_Guide/). 77 | -------------------------------------------------------------------------------- /_projects/gitmate-plugins.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Implement GitMate Plugins for coala" 3 | desc: "GitMate.io helps by automating tasks on GitHub and GitLab. There are new 4 | plugins that are specific to coala that should be implemented. " 5 | requirements: 6 | - "The participant should have at least one patch to 7 | [GitMate](https://gitlab.com/gitmate/open-source/gitmate-2) accepted." 8 | mentors: 9 | - nkprince007 10 | - sils 11 | - manu-chroma 12 | initiatives: 13 | - GSoC18 14 | difficulty: medium 15 | issues: 16 | - "https://github.com/coala/projects/issues/488" 17 | - "https://github.com/coala/projects/issues/487" 18 | - "https://github.com/coala/projects/issues/532" 19 | - "https://gitlab.com/gitmate/GitMate-2-ideas/issues/31" 20 | - "https://gitlab.com/gitmate/open-source/gitmate-2/issues/363" 21 | status: completed 22 | tags: 23 | - IGitt 24 | - GitMate 25 | collaborating_projects: 26 | - coala 27 | - GitMate 28 | - IGitt 29 | --- 30 | 31 | [GitMate.io](https://gitmate.io/) is an automation tool for developers. 32 | While it works well, there are a number of plugins that could automate tasks 33 | to save maintainer time (for example automatically close PRs from master). 34 | 35 | [IGitt](https://igitt.gitmate.io/index.html) is a Git hoster abstraction 36 | for python. It's an extensive framework that will help implement GitMate's plugins. 37 | 38 | To get started on GitMate, please follow 39 | [our guide](http://docs.gitmate.io/Developers/Newcomers_Guide/). 40 | 41 | #### Plugin Ideas 42 | 43 | * Reject Pull Requests from master. Should include 44 | instructions on how to create a new branch, fix the master branch, and 45 | resubmit a PR. 46 | * Fixes vs Closes automated checking. 47 | * A squash command to fix a PR with many messy commits. 48 | Should link to the coala's git documentation for future reference 49 | * Automatically mark PRs as WIP if GitMate's coala plugin finds defects. 50 | * Similarly mark PRs as WIP if CI tests fail. 51 | * Auto-merger created to integrate rebase and ff plugins. 52 | 53 | #### Configuration 54 | 55 | Currently, it is difficult to apply the same rules to different repositories. 56 | GitMate should have some method of configuring multiple settings for many 57 | repositories. This configuration management must 58 | support all existing plugins and be capable of supporting new plugins as well. 59 | 60 | #### Milestones 61 | 62 | ##### PREPARATION/BONDING 63 | * GitMate should automatically reject PRs from master of forks. 64 | 65 | ##### CODING PHASE 1 66 | * Fixes vs Closes automated checking should be implemented. 67 | * Implement "recheck" command for cases where issues unrelated to the 68 | PR cause tests to fail. 69 | * Squash command implemented. 70 | * Implement auto-assign issue based on commit mention. 71 | 72 | #### CODING PHASE 2 73 | * GitMate should mark PRs as WIP if GitMate's coala plugin finds defects. 74 | * GitMate should mark PRs as WIP if CI tests fail. 75 | * Configuration management should support plugins created for this project. 76 | 77 | #### CODING PHASE 3 78 | * Auto-merger created to integrate rebase and ff plugins. 79 | * All plugins must have sufficient tests and documentation. 80 | * Configuration management completed. 81 | -------------------------------------------------------------------------------- /_projects/gitmate-testing.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - GitMate 4 | desc: "GitMate.io is now an MVP with proper unit tests. However, we still lack 5 | support for quick integration tests on feature additions and bug fixes. 6 | Kudos, if you could help us with that." 7 | developers_involved: [] 8 | difficulty: medium 9 | initiatives: 10 | - GSoC 11 | - RGSoC 12 | issues: 13 | - "https://gitlab.com/gitmate/open-source/gitmate-2/issues/245" 14 | - "https://gitlab.com/gitmate/open-source/gitmate-2/issues/294" 15 | markdown: gitmate-testing.md 16 | mentors: 17 | - nkprince007 18 | - sils 19 | - fneu 20 | name: "Improve testing on GitMate" 21 | requirements: 22 | - "The participant should have at least one patch accepted to 23 | [GitMate](https://gitlab.com/gitmate/open-source/gitmate-2)." 24 | - "The participant should demonstrate that he can run unit tests from the 25 | shell in his proposal." 26 | - "The participant should have sufficient knowledge in dealing with py.test 27 | and Django." 28 | status: disabled 29 | tags: 30 | - GitMate 31 | - py.test 32 | - Django 33 | --- 34 | 35 | [GitMate.io](https://gitmate.io/) is an automation tool for developers on their 36 | GitHub and GitLab repositories. 37 | 38 | The goals of this project are: 39 | 40 | - Add integration testing to GitMate for testing on live repositories whenever 41 | new features are added or bug fixes. 42 | - Allow tests to be run in parallel in all possible combinations. 43 | (i.e run the plugin tests in any order). 44 | - Speeding up and improving the current testing architecture. 45 | 46 | The scope of this project is aimed at improving the current testing scenario 47 | under GitMate. As of now, we have complex and huge list of mocking operations 48 | on every testcase in use under gitmate. For e.g., have a look at one of the 49 | test cases in **ack** plugin. 50 | 51 | ```python 52 | @patch.object(GitLabMergeRequest, 'commits', new_callable=PropertyMock) 53 | @patch.object(GitLabCommit, 'unified_diff', new_callable=PropertyMock) 54 | @patch.object(GitLabCommit, 'message', new_callable=PropertyMock) 55 | @patch.object(GitLabCommit, 'sha', new_callable=PropertyMock) 56 | @patch.object(GitLabCommit, 'get_statuses') 57 | @patch.object(GitLabCommit, 'set_status') 58 | def test_gitlab_unmodified_commit( 59 | self, m_set_status, m_get_statuses, m_sha, m_message, m_diff, m_commits 60 | ): 61 | m_get_statuses.return_value = ( 62 | CommitStatus(Status.SUCCESS, 'Good to go!', 63 | 'review/gitmate/manual', 'https://gitmate.io'),) 64 | m_diff.return_value = ('--- a/README.md\n' 65 | '+++ b/README.md\n' 66 | '@@ -1,2 +1,4 @@\n' 67 | ' # test\n' 68 | ' a test repo\n' 69 | '+\n' 70 | '+a commiit that can one acknowledge') 71 | m_message.return_value = 'Update README.md' 72 | m_commits.return_value = tuple([self.gl_commit]) 73 | m_sha.return_value = 'f6d2b7c66372236a090a2a74df2e47f42a54456b' 74 | 75 | # actual testing begins 76 | ... 77 | ``` 78 | 79 | We have a whole lot of mocking before the actual testing begins. Therefore, we 80 | would like to see a clearly determined and viable approach with examples as to 81 | how they would simplify the testing in the applicant's proposal. 82 | 83 | Refer our base, 84 | [GitmateTestCase](https://gitlab.com/gitmate/open-source/gitmate-2/blob/master/gitmate_config/tests/test_base.py) 85 | for more details on how our tests are run. 86 | 87 | To get started on GitMate, please follow [our guide](http://docs.gitmate.io/Developers/Newcomers_Guide/). 88 | -------------------------------------------------------------------------------- /_projects/go-bears-on-bsd.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Explore improvements to coala's dependency management through having Go 5 | Linters installed in *BSD systems automatically." 6 | difficulty: medium 7 | initiatives: 8 | - GSoC 9 | issues: 10 | - "https://gitlab.com/coala/package_manager/issues/149" 11 | - "https://github.com/coala/coala-bears/issues/2481" 12 | markdown: go-bears-on-bsd.md 13 | mentors: 14 | - xferra 15 | - yukiisbored 16 | name: "Linter Dependency Management from a Bare-Metal System" 17 | requirements: 18 | - "At least one patch to the coala core should be accepted and merged." 19 | - "The proposal needs to show familiarity with coala's dependency management implementation." 20 | status: disabled 21 | tags: 22 | - Automation 23 | - Installation 24 | - Dependency 25 | --- 26 | 27 | `coala-bears` are of two types, Native Bears which implement all the business 28 | logic themselves and Linter Bears which wrap existing linters and checkers. 29 | Dependencies of bears are mostly language runtimes, language-specific packages 30 | (e.g. python:nltk) or command line tools (e.g. git). Both Native Bears and 31 | Linter Bears have dependencies which need to be installed before they can be 32 | executed. 33 | 34 | `dependency_management` aims to provide Python APIs for dependency management on 35 | various languages and different systems. It is used extensively by coala, 36 | however, it lacks most of the key implementation and documentation in its 37 | current state. 38 | 39 | coala now has [several bears written in 40 | Go](https://github.com/coala/coala-bears/search?q=GoRequirement), [7 of 41 | which](https://github.com/coala/coala-bears/blob/master/bears/go/) are for 42 | validating Go files. They need specific versions of Go and some externally 43 | supplied packages, and currently Go linter bears just assume they are all in 44 | place and work. Go language dependencies are currently managed unversioned in 45 | coala-bears. There is no official way provided for versioning, and though there 46 | are other commonly used mechanisms for installing specific versions of Go repos, 47 | a lot more investigation is needed. 48 | 49 | The end goal is to be able to bootstrap and recursively install all dependencies 50 | on any systems without anything installed other than a base system, but the 51 | scope of a complete solution is too large. A proposal has been made with 52 | suitable scope, which is to automate the installation of Go linter bears onto 53 | bare-metal BSDs. 54 | 55 | Features will mainly be implemented to coala's `dependency_management`. It 56 | should be able to operate system and language-specific package managers to 57 | handle dependencies. It should also resolve package names and versions 58 | automatically using Repology on multiple operating systems. 59 | 60 | #### Milestones 61 | 62 | ##### PREPARATION/BONDING 63 | 64 | * The student has identified most of the related problems. 65 | * The student has came up with a workflow of how dependencies would be managed 66 | across multiple operating systems and package managers. 67 | 68 | ##### CODING PHASE 1 69 | 70 | * The student has identified and compiled the dependencies of the Go Linter into 71 | `coala-bears`. 72 | * The student has ensured at least one Repology metadata for the Go Linter is in 73 | place and correct. 74 | * The student has deployed a personal FreeBSD CI server and linked it to the 75 | working repo. 76 | * The student has implemented support for FreeBSD's default package manager 77 | [pkg](https://github.com/freebsd/pkg) and test mocks in 78 | `dependency_management`. 79 | * The student has started implementing bootstrap features for bare-metal 80 | systems. 81 | 82 | ##### CODING PHASE 2 83 | 84 | * The student has ensured all Repology metadata for the Go Linter is in place 85 | and correct. 86 | * At least two (the latest and the specified) version of Go dependencies are 87 | handled automatically on FreeBSD. 88 | * The student has designed and started implementing a CLI tool which handles 89 | dependency management requests and wraps the existing `dependency_management`. 90 | * Documentation added and enhanced for `dependency_management`. 91 | 92 | ##### CODING PHASE 3 93 | 94 | * The student has collaborated with the other participant to ensure 95 | Repology-awared metadata pulls work for Go Linter. 96 | * The project’s ability of handling at least two versions of Go dependencies on 97 | BSDs (and possibly other more obscure OS like Alpine Linux) has been 98 | implemented and tested. 99 | * The student has set up an official CI server to the working repo for testing 100 | on FreeBSD. 101 | * Documentation added on how to do the same for new Linter Bears to 102 | [Writing Linter Bears](https://api.coala.io/en/latest/Developers/Writing_Linter_Bears.html). 103 | -------------------------------------------------------------------------------- /_projects/i-gitt-scm-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "IGitt SCM support" 3 | desc: "Add support for git hosters in IGitt and convert coala VCS bears to 4 | use IGitt" 5 | difficulty: medium 6 | requirements: 7 | - "An enhancement to the coala VCS bears" 8 | - "An enhancement to IGitt" 9 | initiatives: 10 | - GSoC17 11 | collaborating_projects: 12 | - coala 13 | - IGitt 14 | tags: 15 | - BitBucket 16 | - Gerrit 17 | - Phabricator 18 | - Fossil 19 | - Launchpad 20 | --- 21 | 22 | [IGitt](https://gitlab.com/gitmate/open-source/IGitt) is a simple library 23 | that allows you to access various git hosting services like GitHub, GitLab 24 | and so on via one unified python interface. 25 | 26 | The coala bears project provides support for git and mercurial VCS but it 27 | does not use IGitt. With this project, VCS in coala-bears should be 28 | simplified using IGitt. 29 | 30 | However, there are some git hosters that are not yet supported by IGitt. 31 | One such hoster is BitBucket. So it is necessary to add BitBucket support to 32 | IGitt before using it to convert the VCS bears in coala-bears. 33 | 34 | Other git hosters like Gerrit and Phabricator are important for IGitt adoption 35 | into large OSS organizations. So are some other non-git SCM, such as Fossil 36 | and Launchpad. 37 | 38 | Support for all these git hosters should be added to IGitt. 39 | 40 | A recommended preparation task in addition to already mentioned requirements 41 | for this project is to make an enhancement to https://github.com/guyzmo/git-repo 42 | 43 | #### Milestones 44 | 45 | ##### GSOC 2018 COMMUNITY/BONDING 46 | 47 | * Create a cEP describing the details of how support for additional git 48 | hosters will be added to IGitt. 49 | * Understand how bears for VCS are implemented in coala bears and describe 50 | details of how IGitt will be used to improve them. 51 | * The participant has a merged enhancement to IGitt. 52 | * The participant has completed the newcomer process. 53 | 54 | ##### CODING PHASE 1 55 | 56 | * Add BitBucket (git & mecurial) support to IGitt. 57 | * Convert the coala VCS bears to use IGitt. 58 | 59 | ##### CODING PHASE 2 60 | 61 | * A copy of IGitt should be imported to a BitBucket hg repository 62 | * Allow CI & coala enabled checking commits. 63 | * Develop new backends in BitBucket hg repository. 64 | * Add Gerrit and Phabricator support to IGitt. 65 | 66 | ##### CODING PHASE 3 67 | 68 | * Submit the new backends to the main IGitt repo hosted on GitLab. 69 | * Add Fossil and Launchpad support to IGitt. 70 | -------------------------------------------------------------------------------- /_projects/implement-metrics-for-coala.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "There is more to software quality than just passing builds - coala 5 | should support generating metrics for your code." 6 | difficulty: high 7 | initiatives: 8 | - GSoC 9 | - RGSoC 10 | issues: 11 | - "https://github.com/coala/coala/issues/759" 12 | markdown: implement-metrics-for-coala.md 13 | mentors: 14 | - fneu 15 | - jayvdb 16 | name: "Implement Metrics for coala" 17 | requirements: 18 | - "At least one patch to the coala core should be accepted and merged." 19 | - "The student should be familiar with ongoing technical [cEPs](https://coala.io/cep)." 20 | - "The proposal needs to contain a clear concept." 21 | tags: 22 | - Core 23 | - Bears 24 | --- 25 | There is more to software quality than just passing builds. A wide variety 26 | of design principles influence software quality, and some of them can be 27 | measured objectively by so-called 28 | [software metrics](https://en.wikipedia.org/wiki/Software_metric). 29 | Software metrics are important because they produce quantifiable measurements 30 | at different stages of software development which have numerous valuable 31 | applications in schedule and budget planning, cost estimation, quality 32 | assurance testing, software debugging, software performance optimization, and 33 | optimal personnel task assignments. They are crucial when it comes to quality 34 | assurance because source code metrics for quality assurance aims at writing 35 | maintainable code with less bugs. coala offers a good base for the 36 | implementation or wrapping of algorithms that calculate these metrics from a 37 | piece of code. The goal of this project is to implement a module in coala that 38 | can produce software metrics. 39 | 40 | Picking the right metrics is important and this project aims at implementing 41 | an API along with a set of Bears for handling and display of software metrics 42 | in coala. 43 | 44 | #### Milestones 45 | 46 | ##### PREPARATION/BONDING 47 | 48 | * The applicant has researched and created a list of tools to use. 49 | * The applicant has created CLI and web UI mockups for metrics. 50 | * The applicant has created a [cEPs](https://coala.io/cep) for his project. 51 | 52 | ##### CODING PHASE 1 53 | 54 | * The API for bears to yield metrics is implemented. 55 | * At least one Bear is implemented which uses this API. 56 | * A working (not clean or merged!) prototype of the CLI visualization 57 | exists. 58 | 59 | ##### CODING PHASE 2 60 | 61 | * The coala CLI can visualize metrics. 62 | * The other coala binaries can handle metrics. 63 | * The API and Bears are fully documented and tested. 64 | 65 | ##### CODING PHASE 3 66 | 67 | * At least one more Bear using this API is implemented. 68 | * All Bears are fully documented and tested. 69 | * A tutorial is merged which contains instructions on how to generate and 70 | visualize metrics for a project. 71 | -------------------------------------------------------------------------------- /_projects/improve-corobo.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Improve plugins, introduce new plugins, setup new configuration method" 5 | developers_involved: [] 6 | difficulty: medium 7 | initiatives: 8 | - GSoC 9 | issues: 10 | - "https://github.com/coala/projects/issues/688" 11 | - "https://github.com/coala/corobo/issues/311" 12 | - "https://github.com/coala/corobo/issues/480" 13 | - "https://github.com/coala/corobo/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fconfig" 14 | markdown: improve-corobo.md 15 | mentors: 16 | - abhishalya 17 | - nvzard 18 | name: "Improve corobo" 19 | requirements: 20 | - "At least one patch to corobo should be accepted and merged." 21 | - "The proposal needs to contain a clear concept." 22 | tags: 23 | - community 24 | - corobo 25 | --- 26 | 27 | Repository: https://github.com/coala/corobo 28 | 29 | corobo is a collection of [errbot](http://errbot.io) chatbot framework plugins. 30 | 31 | The primary objective of this project is to improve corobo by solving as many 32 | pending issues as possible along with introducing new plugins which will ensure 33 | smooth functioning in the community. 34 | 35 | It is also necessary to implement better configuration for the bot and 36 | eliminate the use of environment variables which is hacky and a better 37 | solution is possible. 38 | Refer: https://github.com/coala/corobo/issues/574#issuecomment-401006387 39 | 40 | #### Improvements which can be made to the existing plugins: 41 | 42 | * Adapt LabHub plugin to use the most recent release of IGitt. 43 | * Deprecate use of github3 and migrate plugins to use IGitt. 44 | * Handle users with different GitHub and GitLab usernames. 45 | * Delay loading GitHub org member list when not needed. 46 | * Implement changes to handle other backends (Eg. Zulip). 47 | * Currently, the use of DefaultConfigMixin is not the best solution for 48 | configuration. Implement a solution so that other orgs won't need the 49 | * Mixin while configuring their plugins. 50 | * Convince at least one other organization to use corobo in their chat room. 51 | * Implement/Modify plugins to make handling of events like GCI/GSoC easy. 52 | 53 | ``` 54 | Eg: 55 | >corobo set current event GCI 56 | @/all, GCI has been started, so you can’t assign GCI related issues until the 57 | event ends. 58 | ``` 59 | 60 | #### New plugin ideas: 61 | 62 | * Plugin for corobo Usage Stats. 63 | * Congratulate people who have their first commit merged. 64 | * Listen for invite acceptance and provide more info based on that. 65 | * Plugin for voting. 66 | * All short and partial issues/PR URIs. 67 | * Plugin to remove labels from issues. 68 | * Announce unmerged PR closes on the most appropriate room. 69 | 70 | ``` 71 | Eg: 72 | >corobo remove label area/gci from coala/corobo 73 | @user, successfully removed area/gci label from 10 issues in coala/corobo 74 | ``` 75 | -------------------------------------------------------------------------------- /_projects/integrate-pyflakes-AST.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - Pyflakes 5 | desc: "Integrate pyflakes-enhanced AST into coala so that bears can access it." 6 | difficulty: medium 7 | initiatives: 8 | - GSoC18 9 | - RGSoC 10 | issues: [] 11 | markdown: integrate-pyflakes-AST.md 12 | mentors: 13 | - jayvdb 14 | - myint 15 | - adhikasp 16 | name: "Integrate pyflakes-enhanced AST into coala" 17 | requirements: 18 | - "The participant has a patch to any bear merged. Check out 19 | [existing bear proposal](https://github.com/coala/coala-bears/issues)." 20 | - "The participant has a patch to pyflakes merged. Check out 21 | [easy task](https://bugs.launchpad.net/pyflakes/+bugs?field.tag=easy)." 22 | status: completed 23 | tags: 24 | - Bears 25 | - Pyflakes 26 | --- 27 | flake8 has many plugins which are commonly used in the python development 28 | community. flake8 is a wrapper, similar to coala, that provides the 29 | AST to its plugins. Instead of coala using the flake8 30 | wrapper, which adds another level of complexity and uncertainty with regards 31 | to configuration, coala would like to directly load the python-enhanced AST 32 | and invoke the plugins. 33 | 34 | This allows the coala and flake8 communities to cooperate on plugin 35 | development using a common plugin framework. 36 | 37 | This project focuses on integrating the 38 | [`pyflakes`](https://pypi.python.org/pypi/pyflakes)-enhanced 39 | [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) into coala and 40 | redesign flake8 plugins 41 | [`flake8-future-import`](https://github.com/xZise/flake8-future-import) and 42 | [`flake8-builtins`](https://github.com/gforcada/flake8-builtins) so that they 43 | use pyflakes-enhanced AST. 44 | A seperate wrapper is also needed to be designed so that the pre-existing 45 | plugins can work without any modification. 46 | 47 | This project involves creating a meta bear like 48 | [AnnotationBear](https://github.com/coala/coala-bears/blob/1892b64722f1c10bd2a29611af4dcc18ad76af3a/bears/general/AnnotationBear.py) 49 | and [ClangBear](https://github.com/coala/coala-bears/blob/27a06d19076633a4e796472cf6d6ad55c27045c5/bears/c_languages/ClangBear.py), 50 | say PyflakesASTBear. Then use this bear to redesign the flake8 AST plugins. 51 | Then create a seperate meta bear that wraps flake8 and allows to invoke existing flake8 plugins. 52 | Tutorials for writing and testing bears can be found in our 53 | [documentation](https://api.coala.io). 54 | 55 | The flake8 plugins needed to installed can be added to a dynamically created 56 | venv. Check out 57 | [this issue](https://gitlab.com/coala/package_manager/issues/25). 58 | 59 | #### Milestones 60 | 61 | ##### PREPARARION/BONDING 62 | 63 | * The participant should understand the concept of how to integrate 64 | pyflakes-enhanced AST into coala by writing a meta-bear and how to use this 65 | meta-bear to wrap the flake8 plugins. 66 | 67 | ##### CODING PHASE 1 68 | 69 | * Integrate pyflakes-enhanced AST into coala by writing a meta bear i.e 70 | PyflakesASTBear. 71 | * Write tests for the meta-bear. 72 | * Document the meta-bear. 73 | 74 | ##### CODING PHASE 2 75 | 76 | * Write bears that provides functionality of `flake8-future-import` 77 | and `flake8-builtins` using PyflakesASTBear. 78 | * Write tests for the resulting bears. 79 | * Document the resulting bears. 80 | 81 | ##### CODING PHASE 3 82 | 83 | * Write a bear that wraps `flake8` so that pre-existing plugins can work as it is. 84 | * Write tests for the resulting bear. 85 | * Document the meta-bear. 86 | -------------------------------------------------------------------------------- /_projects/jetbrains-ide-plugin.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - jetbrains 5 | desc: "Offer a general mechanism of highlighting code analysis results from 6 | external tools in jetbrain IDE, the primary goal is to support coala." 7 | difficulty: high 8 | initiatives: 9 | - GSoC19 10 | - RGSoC 11 | issues: 12 | - "https://github.com/coala/coala/issues/2019" 13 | markdown: jetbrains-ide-plugin.md 14 | mentors: 15 | - traff 16 | name: "Plugin for jetbrains IDEs" 17 | requirements: 18 | - "The applicant should have at least one patch accepted to any of the coala plugins." 19 | - "The applicant shoule be familiar with jetbrains IDEs, e.g. PyCharm, IntelliJ IDEA." 20 | status: completed 21 | tags: 22 | - "Jetbrains IDEs" 23 | - Plugins 24 | --- 25 | 26 | JetBrains is a software vendor specializing in the creation of intelligent 27 | development tools. 28 | JetBrains IDEs includes IntelliJ IDEA, PyCharm, CLion, Gogland and so on. 29 | 30 | The idea behind the support of coala is that it's better to have a general 31 | mechanism of highlighting code analysis results from external tools, 32 | PyCharm already has something in that direction for PEP8. 33 | Of course the primary goal is to support coala, but the API should be done in a 34 | way to be able to support others. 35 | 36 | The project is divided into two parts: 37 | 38 | 1. Have a general mechanism of highlighting code analysis results from external tools. 39 | 2. Offer a plugin to support coala. 40 | 41 | ##### Features 42 | 43 | * Implement a linter for languages supported by coala. 44 | * Support all jetbrains IDEs. 45 | * (Long-term, not in this project) Support for automatically formatting code. 46 | * (Long-term, not in this project) Coafile support. 47 | * Support coafile syntax highlight. 48 | * Coloring files that should be checked in the Project View. 49 | * Support templates. 50 | 51 | #### Milestones 52 | 53 | ##### PREPARATION/BONDING 54 | 55 | * A concept exists for how to support showing result for code analysis tools. 56 | * A Mock plugin set up. 57 | 58 | ##### CODING PHASE 1 59 | 60 | * A working plugin with minimal functionality exists. 61 | * Corresponding test cases exist. 62 | * Corresponding documentation exists. 63 | 64 | ##### CODING PHASE 2 65 | 66 | ##### CODING PHASE 3 67 | 68 | * A working plugin with full functionality exists. 69 | * A full covering testsuite exists. 70 | * Full Documentation exists. 71 | -------------------------------------------------------------------------------- /_projects/meta-review.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Implement a meta-review system that tracks and provides meaningful analysis of reactions on reviews." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC18 8 | issues: 9 | - "https://github.com/coala/projects/issues/480" 10 | markdown: meta-review.md 11 | mentors: 12 | - hemangsk 13 | - blazeu 14 | - alisianoi 15 | - andrewda 16 | name: "Meta-review" 17 | requirements: 18 | - "The applicant should have at least one patch merged to any of the coala repositories." 19 | - "The applicant should be familiar with GitHub GraphQL API and JavaScript." 20 | status: completed 21 | tags: 22 | - community 23 | - web 24 | --- 25 | 26 | The meta-review project is about building a meta-review system, 27 | similar to a meta-moderation system, that can track emoji responses to 28 | review comments. These responses are to be collected, processed and displayed 29 | on [gh-board](https://github.com/coala/gh-board), which is a nice serverless 30 | kanban board. 31 | 32 | People including the author of pull request respond to comments by attaching 33 | emojis. Those emojis are called meta-review, or 34 | [reactions](https://developer.github.com/v4/enum/reactioncontent/). THUMBS_UP 35 | and THUMBS_DOWN, together with other reactions, are used by people especially 36 | the author of pull request to publicly acknowledge or reject review comments. 37 | This provides feedback to reviewers and all other members. 38 | 39 | However, those reactions spread over all PRs and are not collected and 40 | analyzed. By tracking reactions, a nice feedback loop would be created 41 | for both senior and junior reviewers. Also, this information (e.g. some 42 | pre-fetching code and json files) can be used as newcomer metrics in newcomer 43 | gamification. 44 | 45 | One goal of this project is to encourage people to do meta-reviews, 46 | systematically. Worst case is that the tracking stores in the json which 47 | PR do not have meta-reviews, and gh-board shows only a list of those PRs 48 | (and the user must then find the reviews in GitHub PR webapp, and do 49 | meta-review there). An improvement is to store the identifier of the PR 50 | comments which do not have meta-reviews, and gh-board links to the PR 51 | review comment in GitHub PR webapp. In the ultimate version, gh-board 52 | would show the review comments. 53 | 54 | Also, to encourage people to do more meta-reviews, statistics of meta-reviews 55 | are to be collected and analysed. People who do meta-reviews will get scores 56 | according to some metrics. A ranking list is to be displayed on gh-board. 57 | 58 | The scope of this project would exclude non-public meta-reviews. That is, 59 | there would not be any anonymous meta-reviews as that introduces too many 60 | additional complexities. The public only version would be used for 61 | long time before adding support for non-public meta-reviews. 62 | 63 | To conclude, this project builds a meta-review system on gh-board to display 64 | statistics (score ranking, meta-reviews in need), and encourage people to 65 | do meta-review. 66 | 67 | #### Milestones 68 | 69 | ##### PREPARATION/BONDING 70 | 71 | - The applicant has proposed and merged a cEP of how meta-reviews could be 72 | tracked and handled. 73 | - The applicant has created mockups for the frontend. 74 | - The applicant gets acquainted with MaterializeCSS. 75 | - The applicant gets acquainted with data visualization 76 | library (e.g. d3.js). 77 | - The applicant gets 78 | [gh-board#13](https://github.com/coala/gh-board/issues/13) fixed. 79 | - The applicant modernizes existing React component code in gh-board project. 80 | 81 | ##### CODING PHASE 1 82 | 83 | - A basic gh-board that displays ranking list of meta-review scores exists. 84 | - Basic documentation including a short video showing the functionality 85 | working exists. 86 | 87 | ##### CODING PHASE 2 88 | 89 | - A basic gh-board that displays review comments that need meta-review exists. 90 | - Basic documentation including a short video showing the functionality 91 | working exists. 92 | 93 | ##### CODING PHASE 3 94 | 95 | - A sophisticated gh-board exists. Additional features may include: 96 | - Overall ranking list & recent ranking list with sorting option. 97 | - Display comments that need meta-review in an ultimate way. 98 | - Display visitor's own meta-reviews if the visitor logs in. 99 | - Full documentation including one or more short videos showing the 100 | functionality working exists. 101 | -------------------------------------------------------------------------------- /_projects/nested-languages.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Multiple programming languages can coexist in the same source 5 | file - coala should support writing code analysis that only works on 6 | parts of files." 7 | difficulty: high 8 | initiatives: 9 | - GSoC19 10 | - RGSoC 11 | issues: 12 | - "https://github.com/coala/coala/issues/1690" 13 | markdown: nested-languages.md 14 | mentors: 15 | - corona10 16 | - Udayan12167 17 | name: "Handle Nested Programming Languages" 18 | requirements: 19 | - "At least one patch to the coala core should be accepted and merged." 20 | - "The student should be familiar with ongoing technical [cEPs](https://coala.io/cep)." 21 | - "The proposal needs to contain a clear concept." 22 | status: completed 23 | tags: 24 | - Core 25 | - Bears 26 | --- 27 | Multiple programming languages can coexist in a single source file. coala would 28 | benefit from the ability to determine the programming language of each part of 29 | a file. If we have e.g. a PHP file, it is likely that we'd have chunks of html 30 | inside a few of them. We would like coala to be able to still run meaningful 31 | analysis on those files. 32 | Other examples include: 33 | 34 | * awk inside bash 35 | * JSON inside Javascript 36 | * HTML, LaTeX or others inside Jinja2 37 | 38 | This project is about enabling coala to deal with those situations and allow 39 | people to write code analysis similar to how they already do it while being 40 | applicable to the right locations at the right files. 41 | 42 | There are several ways to approach this. The most straightforward would be to identifiy common combinations 43 | of languages and come up with a clever way to implement support for these combinations individually. A more 44 | advanced path would be to come up with a more abstract way to define how arbitrary combinations could be supported. 45 | 46 | 47 | #### Milestones 48 | 49 | ##### PREPARATION/BONDING 50 | 51 | * The applicant is familiar with core coala codebase. 52 | * The applicant has proposed and merged a [cEP](https://coala.io/cep) of how 53 | multiple languages inside a single source file could be handled. 54 | 55 | ##### CODING PHASE 1 56 | 57 | * A working example of a specific combination of programming languages exists. 58 | 59 | ##### CODING PHASE 2 60 | 61 | * At least three common combinations of languages are supported. 62 | * OR if applicable an abstract method of combining languages has been developed 63 | and at least one bear exists which uses this method. 64 | 65 | ##### CODING PHASE 3 66 | 67 | * At least 5 common combinations of languages are supported either via explicit 68 | implementations or an abstract system to combine arbitrary languages. 69 | * Several working bears exist that are able to handle examples of nested languages. 70 | -------------------------------------------------------------------------------- /_projects/newcomer-metrics.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Provide public metrics about newcomers and the newcomer process." 5 | difficulty: medium 6 | initiatives: 7 | - GSoC18 8 | issues: [] 9 | markdown: newcomer-metrics.md 10 | mentors: 11 | - jayvdb 12 | - gkrishnan724 13 | - prnvdixit 14 | name: "Newcomer metrics and gamification" 15 | requirements: 16 | - "The student should have patches and PRs in coala/community repo." 17 | - "The student should be familiar with web design tools & trends." 18 | status: completed 19 | tags: 20 | - community 21 | - webservice 22 | --- 23 | 24 | coala tries to be a welcoming organisation for newcomers, giving them clear 25 | pathways and as much direct assistance as needed and possible, and using 26 | automation tools to reduce the load on the core team. 27 | 28 | We need to measure our community's success in this department, in order to 29 | identify problems and constantly improve. We can also use metrics to gamify 30 | this process, allowing newcomers to see how they performed at the newcomer 31 | process compared to other newcomers, and giving badges to newcomers who perform 32 | particularly well, and badges to developers who spend their time assisting a 33 | newcomer through the process successfully. The inverse is also possible, 34 | allowing the core team to evaluate when someone has consumed too much time with 35 | too little progress, and allowing the newcomer and their peers to see cold 36 | facts that show who is taking too long to complete the process. 37 | 38 | The primary metric measured is the time period for each newcomer from first 39 | sighting on github/gitter, to the merge of a PR for a low difficulty issue that 40 | was not created by the newcomer, and a ‘suggestions requested’ review of a low 41 | difficulty PR by another community member and the review endorsed by a 42 | maintainer with a ‘+1’.(meta-reviews) 43 | 44 | This will require that issues are manually downgraded to 'difficulty/newcomer' 45 | if they were not actually the 'difficulty/low' originally expected, and each 46 | newcomer knows they need to have a maintainer super-review their review, and 47 | actively beg for this super-review. 48 | 49 | Some other very basic metrics that can be used are: 50 | 51 | - Number of pushes 52 | - Number of gitmate errors 53 | - Number of reviewer comments 54 | - Number of gitter messages by the newcomer 55 | - Number of gitter messages to the newcomer 56 | 57 | All of those can be improved by considering the size (bytes, etc) in addition to the 'number'. 58 | -------------------------------------------------------------------------------- /_projects/nextgen-action-system.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Next Generation Action System" 3 | desc: "Actions in coala should be improved to allow for more dynamic and suiting actions" 4 | requirements: 5 | - "The applicant must understand how results and actions work in coala." 6 | - "The proposal needs to contain a clear concept." 7 | difficulty: "high" 8 | mentors: 9 | - abhishalya 10 | - Vamshi99 11 | initiatives: 12 | - GSoC19 13 | status: completed 14 | tags: 15 | - core 16 | --- 17 | 18 | Currently, `Result` objects are passed to action objects as parameters when 19 | coala tries to apply an action. This is a bit restrictive as this means that 20 | coala needs to have a global set of actions that it tries to apply on all 21 | `Result` objects. Sure, coala checks if an action `is_applicable()` before it 22 | tries to apply it but it needs to do that for every `Result` that every bear 23 | ever generates. 24 | 25 | We need a way allow results to define actions by themselves, like 26 | `result = Result(actions=[ApplyPatchAction, ...]). Here is the benefit of such 27 | an approach: 28 | * Bears can specify their own actions, for example the GitCommitBear would 29 | highly benefit from this (actions could be added for amending commits). Then, 30 | the bear writers could get much more creative and generate even more useful 31 | bears. 32 | 33 | #### Milestones 34 | 35 | ##### COMMUNITY BONDING 36 | 37 | * Student should have a clear plan and conceptual work must be finished. 38 | * The applicant should know how to work with the community. 39 | 40 | ##### CODING PHASE 1 41 | 42 | * Changes to the `Result` class must be finished including writing tests and documentation. 43 | 44 | ##### CODING PHASE 2 45 | 46 | * Action classes have been revamped so that they allow the above mentioned benefits. 47 | * Refactoring of the existing action classes in order to comply with the above 48 | plan must be at least partially complete. 49 | 50 | ##### CODING PHASE 3 51 | 52 | * All functions/modules that are affected by changes have been refactored. 53 | * coala tutorials and bear writing tutorials have been updated. 54 | * Some new actions have been defined and implemented in a real bear. For 55 | example, an action to amend the commit has been to GitCommitBear. 56 | -------------------------------------------------------------------------------- /_projects/optimize-caching.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Improve coala's caching and IO for the NextGen-Core" 5 | difficulty: medium 6 | initiatives: 7 | - GSoC18 8 | - RGSoC 9 | issues: 10 | - "https://github.com/coala/coala/issues/3530" 11 | - "https://github.com/coala/coala/issues/2912" 12 | - "https://github.com/coala/coala/issues/2541" 13 | - "https://github.com/coala/coala/issues/5136" 14 | markdown: optimize-caching.md 15 | mentors: 16 | - Makman2 17 | - shreyans800755 18 | - fneu 19 | name: "Optimize Caching" 20 | requirements: 21 | - "At least one patch to the coala core should be accepted and merged." 22 | - "The student should be familiar with ongoing technical cEPs especially 23 | [cEP-0002](https://github.com/coala/cEPs/blob/master/cEP-0002.md)." 24 | - "The proposal needs to show some familiarity with coala's caching implementation." 25 | status: completed 26 | tags: 27 | - Core 28 | - Bears 29 | --- 30 | Currently, coala supports caching of project files. With it, coala runs 31 | code analysis only on files that had changed since the last run, giving a 32 | huge amortized performance improvement compared to simply running coala on 33 | everything regardless. But it is still rather slow. On the other hand coala's 34 | NextGen-Core has minimal caching support and needs a caching mechanism better 35 | than the one used by the current core. 36 | 37 | For example, we recently discovered that we have been importing all 38 | the required modules irrespective of the conditional branch the program 39 | takes - some branches do not require some modules. We improved this 40 | by lazy-loading only the required modules as and when they are required - and 41 | this greatly improved coala's startup speed. 42 | 43 | Performance is key to usability - with faster runtimes, users can get on 44 | with their work quicker. And it's fun looking for performance bottlenecks! 45 | 46 | In this project, you're to come up with improved versions of the current caching 47 | strategies used by coala's core and integrate these with the NextGen-Core. 48 | Some enhancements such as ignoring unmodified directories and use of 49 | `FileFactory` and `Directory` classes have been already explored and are to be 50 | implemented as a part of this project. Please refer to the related issues to 51 | learn more about these. 52 | 53 | The student is also highly encouraged to come up with new solutions that may 54 | increase performance even further. 55 | 56 | #### Milestones 57 | 58 | ##### PREPARATION/BONDING 59 | 60 | * The applicant has identified at least 3 other performance bottlenecks that can be 61 | improved. These can be smaller improvements, focussing on one particular 62 | aspect of coala's core. 63 | * The applicant has drafted and merged a [cEP](https://github.com/coala/ceps) 64 | describing all the proposed changes thoroughly. 65 | * Preliminary prototypes have been tested to validate the proposed changes' 66 | performance improvements. 67 | 68 | ##### CODING PHASE 1 69 | 70 | * Thorough tests have been performed to concretely ascertain a measurable 71 | performance gain. 72 | * `Directory` class has been implemented. 73 | * `FileFactory` class has been implemented and the file contents in the 74 | `file-dict` have been replaced with the factory objects. (Both these classes 75 | would later be used for implementing ignore directories functionality) 76 | * The corresponding code is properly tested, documented, reviewed, and merged. 77 | 78 | ##### CODING PHASE 2 79 | 80 | * The Proposed change to ignore unchanged directories has been implemented. 81 | * Thorough tests have been performed to concretely ascertain a measurable 82 | performance gain. 83 | * At least one of the cache control flags have been implemented. 84 | * The corresponding code has been thoroughly tested, documented, reviewed, and 85 | merged. 86 | 87 | ##### CODING PHASE 3 88 | 89 | * All the remaining cache control flags like `--cache-optimize`, 90 | `--cache-compression`, etc have been implemented. 91 | * The corresponding code is properly tested, documented, reviewed, and merged. 92 | * A final report describing the measured performance improvements for the 93 | various implemented techniqes has been published. 94 | -------------------------------------------------------------------------------- /_projects/pr-perftest.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - GitMate 5 | desc: "Essentially a codecov for performance, but smarter." 6 | difficulty: medium 7 | initiatives: 8 | - Paper 9 | issues: [] 10 | markdown: pr-perftest.md 11 | name: "Performance measurement for pull requests" 12 | requirements: 13 | - "Prior experience with commit-based performance testing." 14 | tags: 15 | - coala 16 | - GitMate 17 | - performance 18 | --- 19 | This project is based on the research work done in "Commit-based 20 | performance testing". This is basically taking that research and 21 | applying it to GitMate, creating a Codecov for performance 22 | measurement. 23 | 24 | With this integrated into GitMate, the project could receive direct and 25 | immediate feedback on how a particular pull request affected their 26 | performance. This would also use the previously researched algorithms 27 | to identify the commits that lead to performance changes. 28 | -------------------------------------------------------------------------------- /_projects/python-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | name: "Support for newer Python versions" 5 | desc: "coala should be able to support all major Python 3 versions" 6 | markdown: python-support.md 7 | requirements: 8 | - "The applicant must understand how results and actions work in coala." 9 | - "The proposal needs to contain a clear concept." 10 | difficulty: "high" 11 | mentors: 12 | - abhishalya 13 | - jayvdb 14 | initiatives: 15 | - GSoC 16 | tags: 17 | - core 18 | --- 19 | 20 | Currently, coala only supports Python 3 versions upto 3.6. This is a very 21 | old release and there are reasons why coala was not able to progress to the 22 | newer versions so quickly. The major blocker to this is the dependency 23 | management which has some core issues which are to be solved to improve 24 | the support. 25 | 26 | There are a lot of dependencies which do not have support for all Python 3 27 | versions and to fix this issue we should do one of the two things: 28 | * Drop the package and fix the issue from the coala side. 29 | * Find a workaround with the existing package and patch things on coala. 30 | 31 | Due to recent changes in GSoC with the program being only for 10 weeks 32 | the coding phases below are adjusted accordingly. 33 | 34 | #### Milestones 35 | 36 | ##### COMMUNITY BONDING 37 | 38 | * Student should have a clear plan and conceptual work must be finished. 39 | * The applicant should know how to work with the community. 40 | 41 | ##### CODING PHASE 1 42 | 43 | * Changes to the dependency management must be finished including writing tests 44 | and documentation. 45 | 46 | ##### CODING PHASE 2 47 | 48 | * The coala core should be revamped so they allow the above mentioned benefits. 49 | * Refactoring of the existing CI/CD setup to verify builds on the newly supported 50 | Python versions. 51 | -------------------------------------------------------------------------------- /_projects/quickstart-green-mode.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala-quickstart 4 | - coala 5 | desc: "Generate project compatible config files." 6 | difficulty: medium 7 | initiatives: 8 | - GSoC 9 | - RGSoC 10 | issues: 11 | markdown: quickstart-green-mode.md 12 | mentors: 13 | - satwikkansal 14 | - adtac 15 | - dracarys09 16 | name: "Quickstart Green Mode" 17 | requirements: 18 | - "The applicant should have at least one patch accepted to coala-quickstart 19 | repository." 20 | - "The participant should have an understanding of coala's structure and 21 | config files." 22 | - "The proposal needs to contain a clear concept." 23 | status: completed 24 | tags: 25 | - coala-quickstart 26 | - coala-ci 27 | --- 28 | 29 | coala doesn't help the user unless the user is familiar with its settings and 30 | bears. coala-quickstart is the project to handle this situation by asking the 31 | users general questions about their project and producing a config file to lint 32 | their code. 33 | 34 | Currently coala-quickstart asks the user a lot of questions, and usually 35 | generates a `.coafile` which causes coala-ci to generate errors. 36 | There is a need for production of config files which yield 'green' results 37 | which adapt the bears and their settings according to the project. This mode 38 | would run coala many times in order to answer questions itself, altering bear 39 | settings each time to find the set of settings which produces the least amount 40 | of errors, and where necessary adds ignore for the remaining files. 41 | 42 | **Note:** coala-quickstart also has a `--ci` mode where it skips the questions 43 | that require user interaction while the `--green` mode should determine optimal 44 | answers by running coala and running from its output. 45 | 46 | This will lead to easier and increase in adoption of coala across organizations 47 | and user projects. This would initially configure the bears to agree with the 48 | repo maintainers' existing coding style, that will result in a quickly mergable 49 | Pull Request adding the `.coafile`. They can then make changes to the `.coafile` 50 | and their coding style whenever they want to, or when the bears start supporting 51 | their repositories' intricacies. 52 | 53 | This project also aims to identify many large complex repositories in the early 54 | phases, and work towards detecting those repos' settings automatically and 55 | correctly. 56 | 57 | 58 | #### Milestones 59 | 60 | ##### PREPARATION/BONDING 61 | 62 | - Design documentation about how to approach the problem. 63 | 64 | - Make and merge a cEP addressing the following points: 65 | 66 | - How do you plan to scan through the files for possible bear settings. 67 | 68 | - How do you plan to tackle conflicting bear settings in the whole project. 69 | 70 | - What are you plans on reaching other organizations for adoption of coala 71 | and the green mode config file in their codebase. 72 | 73 | - The participant should get familiar with the coala-quickstart repository 74 | and make plans to utilize the already existing resources provided by 75 | coala-quickstart on collecting metadata and detecting inconsistencies 76 | in the code. 77 | 78 | - The participant should come up with an initial set of organizations to 79 | serve as a measure of the effectiveness of the project in later phases. 80 | 81 | ##### CODING PHASE 1 82 | 83 | - Framework for iterating through files has been constructed. 84 | 85 | - Identify some bears with few *mandatory* settings which are easy to 86 | identify, and simple optional settings based upon the code provided. 87 | 88 | ##### CODING PHASE 2 89 | 90 | - The project is able to deliver config files yielding absolute *green* results. 91 | 92 | - Subtle intricacies and border edge cases have been identified, planned on 93 | how to tackle them. 94 | 95 | ##### CODING PHASE 3 96 | 97 | - Final complete config files are deliverable by the project for any given 98 | codebase. 99 | 100 | - A genuine effort has been made to submit Pull Requests to other orgs with 101 | the generated config file with supplementary CI configuration needed to 102 | run `coala-ci`. 103 | -------------------------------------------------------------------------------- /_projects/result-reporter-tool.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Implement a result reporter tool that converts linter/bear results 5 | into various formats" 6 | difficulty: medium 7 | initiatives: 8 | - GSoC19 9 | issues: 10 | - "https://github.com/coala/projects/issues/555" 11 | - "https://github.com/coala/coala/issues/2757" 12 | - "https://github.com/coala/coala/issues/5910" 13 | - "https://gitlab.com/coala/coala-json/issues/3" 14 | markdown: result-reporter-tool.md 15 | mentors: 16 | - li-boxuan 17 | name: "Result Reporter Tool" 18 | requirements: 19 | - "The applicant should have at least one non-trivial patch merged to 20 | coala or coala-bears." 21 | - "The applicant should be familiar with Python." 22 | - "Familiarity with continuous integration tools (e.g. Jenkins) is a plus." 23 | status: completed 24 | tags: 25 | - Core 26 | - Linter 27 | - CI 28 | --- 29 | 30 | Apart from common CLI output, coala provides json format output. However, there 31 | are other formats which are useful for reporting tests and failures, but coala 32 | does not support at the moment. 33 | 34 | This is not only for coala, result format inconsistencies has been a problem for 35 | a long time. Converting the static analysis results into a test results format 36 | has been done a few times, such as early PEP8 plugins to Jenkins. The mapping 37 | isn't exact, but the benefits of using the test result format is tight 38 | integration with various systems. 39 | 40 | Most commonly used is JUnit format. CircleCI can accept 41 | [this format](https://circleci.com/docs/2.0/collect-test-data). AppVeyor can 42 | receive test results in [XML format](https://www.appveyor.com/docs/running-tests/#uploading-xml-test-results). 43 | Other formats include [TAP](https://testanything.org/), 44 | [Clover](http://openclover.org/doc/manual/latest/ant--clover-report.html), 45 | There are some systems, such as Phabricator, which have a 46 | [custom format](https://github.com/facebook/infer/issues/673) they expect. 47 | 48 | The applicant is welcomed to propose additional ideas around format topic, to 49 | improve coala workflow, continuous integration workflow or linters workflow. 50 | For example, pulling the coala results from CI could be a way to inform newbies 51 | of the style problems with their PRs. Pushing the unit test results as XML to 52 | the CI (using combination XML files if necessary). It might also provide 53 | linters with a solid set of classes and output formats for their CLI, letting 54 | them focus on linting algorithms. 55 | 56 | #### Milestones 57 | 58 | ##### PREPARATION/BONDING 59 | 60 | - The applicant has created and merged a cEP for this project. 61 | - The applicant has done research on different formats, including JUnit, 62 | checkstyle, TAP, Language Server Protocol (LSP), etc. 63 | - The applicant has done research on different formats required by CI 64 | tools and platforms, including Jenkins, Circle CI, Appveyor, Phabricator, etc. 65 | 66 | ##### CODING PHASE 1 67 | 68 | - A tool that converts JSON results to JUnit format is implemented, tested, 69 | and documented. 70 | - Test and add doc regarding how to upload coala results into Circle CI and 71 | Appveyor. 72 | - Add infrastructure (CI, doc) to coala-json repository, where most part of 73 | this project will probably reside. 74 | 75 | ##### CODING PHASE 2 76 | 77 | - Extend the tool to support different formats, including Checkstyle format, 78 | TAP, Clover. 79 | - Test and add doc regarding how to upload coala results into Jenkins and 80 | Phabricator. 81 | - Import converters into coala main repository to improve coala output mode. 82 | 83 | ##### CODING PHASE 3 84 | 85 | - Provide various linters with a solid set of classes and output formats for 86 | their CLI. 87 | - Handle JSON/xml reports from linters before feeding into linter bears. 88 | -------------------------------------------------------------------------------- /_projects/roberta-external-source.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - openroberta 5 | desc: "Create a loader for projects from remote data sources that can be used 6 | from the coala web page in order to provide one click linting for online 7 | projects." 8 | difficulty: high 9 | status: disabled 10 | initiatives: 11 | - GSoC 12 | issues: [] 13 | markdown: roberta-external-source.md 14 | mentors: 15 | - maweki 16 | name: "One click linting for online projects in the browser" 17 | requirements: 18 | - "The applicant should be be familiar with bear creation and XML parsing using xpath or a similar query language" 19 | - "The applicant should be reasonable familiar with the coala codebase and the workings of REST APIs, including 20 | authentication." 21 | - "The applicant has contributed to a relevant coala module, the Open Roberta platform, or both." 22 | tags: 23 | - Bears 24 | - Web 25 | --- 26 | 27 | **Disabled: This project is not available for GSOC 2018. 28 | See OpenRoberta's GSOC 29 | [page](https://summerofcode.withgoogle.com/organizations/6256279438229504/) 30 | if you are interested in working with them** 31 | 32 | For children and students, learning to program becomes increasingly accessible 33 | through programming platforms like the Open Roberta Lab and Code.org, etc.. 34 | While these platforms provide resources and an environment for novices to explore 35 | and learn, the browser-centric nature of the exercises and toolchain makes it hard to retrieve 36 | content, learn about proper project structure, and use third party tools that 37 | are increasingly used by developers, like static code analysis and code generation. 38 | 39 | This proposed project is about loading online resources instead of inserting local files 40 | into the one-click linter on the coala homepage. This will give students the chance 41 | to check the coding style and other interesting properties of their projects in 42 | the browser, without jumping through hoops to retrieve their work from a remote 43 | source, and installing and learning to use coala's command line interface. 44 | 45 | The project should allow, for example, for a student to load and check NEPO-programs from the 46 | Open Robert Lab directly from the browser. This can later be extended to 47 | allow for other remote sources, like code.org, 5code, or github/bitbucket projects 48 | to be checked according to the language hints provided by the respective APIs. 49 | 50 | Open Roberta is a platform for students of any age to program consumer-grade 51 | robotics-hardware in a visual manner, using a blockly-like language called `NEPO`. 52 | Roberta is a long established international project initiated by the Fraunhofer IAIS 53 | that aims at nurturing interest in STEM and robotics in young women and students. 54 | Using Open Roberta as an extensible platform instead of proprietary programmers 55 | specific to certain robotics hardware is an important part of Roberta's main goal 56 | of accessibility and outreach for young women and students of all ages. 57 | 58 | The student will work with members from the coala team, and members from 59 | Fraunhofer IAIS and other Roberta-related projects. The student may acquire 60 | additional certification through Fraunhofer IAIS in Sankt Augustin, Germany. 61 | 62 | #### Milestones 63 | 64 | ##### PREPARATION/BONDING 65 | 66 | * Familiarity with the OpenRoberta partner project is established and a method 67 | for external access is designed and implemented in a basic fashion 68 | * A design goal is reached with the coala project on how to integrate external 69 | data sources into the coala web page, including mock-ups and a prototype 70 | implementation for the UI 71 | 72 | ##### CODING PHASE 1 73 | 74 | * A bear for downloaded NEPO-programs is created that checks for certain simple 75 | properties of the program, like nesting depths and whether any part of the 76 | program tree is undefined. The specific properties shall be defined in the 77 | GSoC application. 78 | * The infrastructure for downloading external resources through the web 79 | interface is established and working in a basic fashion. 80 | 81 | ##### CODING PHASE 2 82 | 83 | * A NEPO program stored on the Open Roberta Lab can be checked from the web interface 84 | * The infrastructure for downloading external resources through the web 85 | interface is well documented and loaders for other resource locations can easily be added 86 | * All necessary changes to the webpage UI are implemented 87 | 88 | ##### CODING PHASE 3 89 | 90 | * A NEPO program stored on the Open Roberta Lab can be checked from the web 91 | interface and a user receives useful advice about the quality of their 92 | project 93 | * A github repository can be checked from the web interface. A useful 94 | collection of bears is chosen using github's project language hints. 95 | -------------------------------------------------------------------------------- /_projects/rstcheck-with-better-sphinx-support.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | - rstcheck 5 | desc: "Add an alternative front end for rstcheck to better support checking Sphinx documents." 6 | difficulty: medium 7 | initiatives: 8 | - GSoC 9 | - RGSoC 10 | issues: [] 11 | markdown: rstcheck-with-better-sphinx-support.md 12 | mentors: 13 | - myint 14 | name: "Improve Sphinx support in rstcheck" 15 | requirements: 16 | - "Familiarity with reStructuredText and Sphinx." 17 | - "Familiarity with nesting code blocks within reStructuredText." 18 | - "Experience with making use of Python packages to create new functionality." 19 | tags: 20 | - reStructuredText 21 | - Sphinx 22 | --- 23 | 24 | Programmers often embed code examples in their documentation. In the 25 | reStructuredText markup format, that is done using code blocks. 26 | [`rstcheck`](https://github.com/myint/rstcheck) is a tool that checks the 27 | syntax of these code blocks. 28 | 29 | `rstcheck` automatically reports any syntax errors it finds in the 30 | documentation. `rstcheck` uses [Docutils](http://docutils.sourceforge.net/) to 31 | parse reStructuredText files and extract code blocks. It then applies syntax 32 | checkers on the code blocks. 33 | 34 | In the case of code blocks containing statically compiled 35 | languages like C++, it can check that the API usage is correct using the C++ 36 | compiler to do the syntax check. This is useful since APIs can change over 37 | time. Having an automated check makes it more likely than the documentation 38 | will match the API of the current code base. 39 | 40 | [Sphinx](http://www.sphinx-doc.org) is a popular documentation generator that 41 | uses and extends reStructuredText. It has its own custom frontend to do the 42 | reStructuredText parsing. 43 | 44 | Currently, the Sphinx support in `rstcheck` is minimal. This results in 45 | [false positives](https://github.com/myint/rstcheck/issues/19) when checking 46 | documents for syntax errors. 47 | 48 | It would be useful to implement an alternative `rstcheck` mode that uses 49 | Sphinx's parsing frontend, `sphinx-build`, instead of normal Docutils frontend. 50 | This would allow `rstcheck` to parse Sphinx documents exactly the same way 51 | Sphinx does. 52 | 53 | * `rstcheck` = `docutils` + code block linting 54 | * `rstcheck-sphinx` = `sphinx-build` + code block linting 55 | 56 | #### Milestones 57 | 58 | ##### PREPARATION/BONDING 59 | 60 | * As an exercise to get familiar with `rstcheck`, add support for another code 61 | block language. The languages currently supported by `rstcheck` are Bash, 62 | Doctest, C, C++, JSON, Python, and reStructuredText. Submit a pull request 63 | with this new feature. 64 | * Create an example Sphinx project for the purposes of experimenting with 65 | `sphinx-build`. Particularly, pay attention to how code blocks are parsed. 66 | Put this in a public repository on GitHub. 67 | 68 | ##### CODING PHASE 1 69 | 70 | * Create a new front end, `rstcheck-sphinx` with first class Sphinx support. It 71 | should use the `sphinx-build` infrastructure to parse the reStructuredText. 72 | * Support parsing code blocks using this new `sphinx-build` based front end. 73 | Use the existing `rstcheck` checkers to lint the code blocks. 74 | * Write unit tests to demonstrate the above functionality. 75 | 76 | ##### CODING PHASE 2 77 | 78 | * Write scripts to automatically test against existing Sphinx projects to check 79 | for false positives in `rstcheck-sphinx`. 80 | * Integrate with the main `rstcheck` script if appropriate. 81 | 82 | ##### CODING PHASE 3 83 | 84 | * Add additional linting support if time permits. This could involve linting 85 | more kinds of languages in code blocks. Or it could involve making the 86 | language support more extendable. 87 | * Integrate with `coala` in the same way the main `rstcheck` script is 88 | integrated. 89 | -------------------------------------------------------------------------------- /_projects/standardised-file-format.md: -------------------------------------------------------------------------------- 1 | --- 2 | collaborating_projects: 3 | - coala 4 | desc: "Provide support for writing configurations using 5 | a standardised file format(TOML)" 6 | difficulty: hard 7 | initiatives: 8 | - GSoC19 9 | markdown: standardised-file-format.md 10 | mentors: 11 | - Nosferatul 12 | - RaiVaibhav 13 | - ksdme 14 | - Marcos Gómez 15 | name: "Support TOML for writing configurations" 16 | requirements: 17 | - "The applicant should have at least one patch merged to 18 | coala" 19 | - "The applicant should be familiar with Python." 20 | - "The applicant should be familiar with coala configuration system" 21 | status: completed 22 | tags: 23 | - Core 24 | - Configuration 25 | - TOML 26 | --- 27 | 28 | This project aims to support writing configuration files using a 29 | standardised file format like TOML. 30 | Currently coala has a INI style config. It has `LineParser` and `ConfParser` 31 | classes to parse the settings into sections. These sections are later executed 32 | by running the appropriate bear. coala also a `ConfWriter` class to write 33 | sections back into settings file like `.coafile` 34 | 35 | This approach has certain limitations. Custom sub-level parsing in 36 | INI style config is tough and error prone. It makes `LineParser` and 37 | `ConfParser` more complex and bug prone and also would slow down the speed of 38 | development. A solution would be to use standardised file format like TOML. 39 | Using `toml.load` on the config file will return a dictionary. This makes 40 | custom sub-level parsing not only easy and accurate but also less error prone. 41 | Also more importantly completely removes the need for `LineParser`. 42 | 43 | TOML provides flexibility, consistency, backwards compatibility and standard. 44 | It has widespread acceptance, documentation and robust parsers. TOML has been 45 | recommended as the configuration file for software packages to specify their 46 | build dependencies. Due to its popularity it offers a reduced learning curve 47 | compared to INI style config. 48 | 49 | This project aims to provide Toml support for coala-quickstart as well. Also 50 | it will create a tool to convert coafile to TOML files and vice versa. 51 | TomlLintBear will be created as part of this project. Also a repository of 52 | good configuration files will be created to allow users to easily bootstrap 53 | their projects. 54 | 55 | As a stretch goal, the project aims to standardise the present coafile syntax 56 | to provide more flexibility. 57 | 58 | #### Milestones 59 | 60 | ##### PREPARATION/BONDING 61 | 62 | - The applicant has created and merged a cEP for this project. 63 | - The applicant should be familiar with the codebase. 64 | - The applicant should know how to work with the community. 65 | - The mappings between `.coafile` to `TOML` must be finalised 66 | 67 | ##### CODING PHASE 1 68 | 69 | - Create the mechanism to load TOML config files. 70 | - Create a class named `TomlConfParser` to load settings from TOML 71 | file into sections. 72 | - Begin work on `TomlConfWriter`. 73 | 74 | ##### CODING PHASE 2 75 | 76 | - Complete `TomlConfWriter` to be able to write sections into 77 | TOML file. 78 | - Create a tool to convert coafile to TOML file and vice versa 79 | - Provide TOML support to coala-quickstart 80 | 81 | ##### CODING PHASE 3 82 | 83 | - Create TomlLintBear 84 | - Create a repository of good configuration files for major languages 85 | - Create user facing documentation on how to write config files in TOML 86 | 87 | Apart from these core milestones, the project shall also try to 88 | fix issues like comment support at https://github.com/uiri/toml. 89 | This will help improve the overall capacity/quality of this project. 90 | -------------------------------------------------------------------------------- /_reports/bkhanale.md: -------------------------------------------------------------------------------- 1 | --- 2 | categories: 3 | - GSoC 4 | - 2019 5 | - StatusReport 6 | date: 2019-08-24 7 | student: Bhushan Khanale 8 | organisation: coala 9 | organisation_link: https://coala.io 10 | project: Improve Generic Bear Quality 11 | project_link: https://summerofcode.withgoogle.com/projects/#4866569388163072 12 | tarball: https://github.com/bkhanale/GSoCReport/raw/master/ProjectPatches.tar.gz 13 | sha256sum: da098e0c89e14ba21a046e73eb56117fc44500fe3ce92cf00f0cb1d2cab71199 14 | mentors: > 15 | [Sangam Kumar](https://github.com/sangamcse), 16 | [Abhinav Kaushlya](https://github.com/abhishalya) 17 | phase: 18 | - Bonding : https://gitlab.com/coala/GSoC/gsoc-2019/-/milestones/2 19 | - Phase 1 : https://gitlab.com/coala/GSoC/gsoc-2019/-/milestones/3 20 | - Phase 2 : https://gitlab.com/coala/GSoC/gsoc-2019/-/milestones/4 21 | - Phase 3 : https://gitlab.com/coala/GSoC/gsoc-2019/-/milestones/5 22 | bio: > 23 | I'm a final year student of Computer Engineering at International Institute 24 | of Information Technology, Bhubaneswar. I worked on [coala](https://coala.io) 25 | project during my summer on improving the generic bear quality. I implemented 26 | few new bears providing more usability of coala. I also worked on coala's 27 | package manager giving them few more features to work with. 28 | social: 29 | - GitHub: 30 | - username: bkhanale 31 | - link: https://github.com/bkhanale 32 | - GitLab: 33 | - username: bkhanale 34 | - link: https://gitlab.com/bkhanale 35 | - Gitter: 36 | - username: bkhanale 37 | - link: https://gitter.im/bkhanale 38 | - Openhub: 39 | - username: bkhanale 40 | - link: https://www.openhub.net/accounts/bkhanale 41 | email: bkhanale@gmail.com 42 | blog: https://medium.com/@bkhanale 43 | activity: 44 | - 1: 45 | - repo: cEPs 46 | - link: https://github.com/coala/cEPs/pull/184 47 | - details: > 48 | cEP-0031: Improve Generic Bear Quality 49 | - 2: 50 | - repo: coala 51 | - link: https://github.com/coala/coala/pull/6026 52 | - details: > 53 | Add `require_files` settings 54 | - 3: 55 | - repo: coala-bears 56 | - link: https://github.com/coala/coala-bears/pull/2912 57 | - details: > 58 | bears/general: Add FileModeBear 59 | - 4: 60 | - repo: coala-bears 61 | - link: https://github.com/coala/coala-bears/pull/2928 62 | - details: > 63 | bears/general: Add OutdatedDependencyBear 64 | - 5: 65 | - repo: coala-bears 66 | - link: https://github.com/coala/coala-bears/pull/2934 67 | - details: > 68 | bears/general: Add RegexLintBear 69 | - 6: 70 | - repo: coala-bears 71 | - link: https://github.com/coala/coala-bears/pull/2935 72 | - details: > 73 | bears/python: Add RequirementsCheckBear 74 | - 7: 75 | - repo: coala-bears 76 | - link: https://github.com/coala/coala-bears/commit/f9aa8c3bf94b0be7d9a80de0926d7b13382dee09 77 | - details: > 78 | IndentationBear: Ignore doc comments 79 | - 8: 80 | - repo: dependency_management 81 | - link: https://gitlab.com/coala/package_manager/merge_requests/170 82 | - details: > 83 | Add `get_latest_version` for PipRequirement and NpmRequirement 84 | --- 85 | 86 | ### Improve Generic Bear Quality 87 | 88 | #### Work Done 89 | 90 | 1. coala now has new bears (yet to be merged) namely `FileModeBear`, 91 | `RequirementsCheckBear`, `OutdatedDependencyBear` and `RegexLintBear`. 92 | 93 | 2. coala is also set to have two new settings `require_files_not_empty` and 94 | `require_files_for_each_glob` which are responsible to check for the `files` 95 | setting to not evaluate empty and to require at least one file match for each 96 | glob in `files`. 97 | 98 | 3. coala's package manager has new function `get_latest_version` (currently 99 | only for `PipRequirement` and `NpmRequirement` classes) to fetch the latest 100 | version for the given package. 101 | 102 | 4. `IndentationBear` now support new setting to ignore docstrings. 103 | 104 | #### Challenges 105 | 106 | For me the most challenging part was to design the approaches for the bears. 107 | Some of the bears like `OutdatedDependencyBear` and `RequirementsCheckBear` 108 | were much difficult to design. The `FileModeBear` was another challenge given 109 | that it had to work on both Windows and Linux platforms. The process of 110 | designing the approach and then implementing it with a full coverage was 111 | probably the most challenging and interesting part of my project. 112 | 113 | #### Work to be done 114 | 115 | 1. MarkdownBear currently doesn't emit the issues with the patches and it 116 | reduces the usability of the bear. Currently, there is stable fix for this issue 117 | due to the architecture of remark-lint tool. Although, in future this might 118 | change and the bear would also need to be updated. 119 | 120 | 2. The OutdatedDependencyBear currently doesn't support the npm requirements and 121 | this needs a further development in the solution already present for pip 122 | requirement type. 123 | -------------------------------------------------------------------------------- /_reports/example.md: -------------------------------------------------------------------------------- 1 | 57 | 58 | ### 59 | 60 | #### Work Done 61 | 62 | 63 | 64 | #### Challenges 65 | 66 | 67 | 68 | #### Work to be done 69 | 70 | 71 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "root": "data/locale/" 3 | } 4 | -------------------------------------------------------------------------------- /data/admins.json: -------------------------------------------------------------------------------- 1 | ["sims1253", "jayvdb", "sils", "fneu"] 2 | -------------------------------------------------------------------------------- /data/faq.liquid: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | [ 4 | {% for faq in site.faq %} 5 | { 6 | "question" : "{{ faq.question }}", 7 | "url" : "{{ faq.url }}", 8 | "markdown" : "{{ faq.path | replace: '_faq/', ''}}" 9 | }{% unless forloop.last %},{% endunless %}{% endfor %} 10 | ] 11 | -------------------------------------------------------------------------------- /data/locale/LANGS.md: -------------------------------------------------------------------------------- 1 | # Languages 2 | 3 | * [English](en/) 4 | * [Indonesian](id/) 5 | 6 | -------------------------------------------------------------------------------- /data/locale/en/README.md: -------------------------------------------------------------------------------- 1 | ../../../README.md -------------------------------------------------------------------------------- /data/locale/en/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | ### Google Code-in tasks 4 | 5 | #### Using coala 6 | * [use coala](projects/use-coala.md) 7 | * [Use coala - Advanced](projects/use-coala-2.md) 8 | * [Implement coala](projects/use-coala-3.md) 9 | 10 | #### Using linters 11 | 12 | * [Add repository license](projects/add-repo-license.md) 13 | 14 | ### Google Summer of Code 15 | 16 | #### Proposed projects 17 | 18 | * [Integrate ANTLR v4 into coala](projects/antlr-v4.md) 19 | * [Improve Lint Bear Quality](projects/bear-updates.md) 20 | * [Researching commit-based performance testing](projects/commit-based-perftest.md) 21 | * [Real-time team communication bridge](projects/communication-bridge.md) 22 | * [Create Jenkins Plugin](projects/create-jenkins_plugin.md) 23 | * [Debug and Profile Bears](projects/debug-profile.md) 24 | * [Cohesive Editor Support](projects/editor-support.md) 25 | * [Improve Generic Bear Quality](projects/generic-bears.md) 26 | * [Implement Metrics for coala](projects/implement-metrics-for-coala.md) 27 | * [Improve Diff Handling](projects/improve-diff-handling.md) 28 | * [Improve installation of coala and coala-bears](projects/improve-installation.md) 29 | * [Integrate pyflakes-enhanced AST into coala](projects/integrate-pyflakes-AST.md) 30 | * [Plugin for jetbrains IDEs](projects/jetbrains-ide-plugin.md) 31 | * [Handle Nested Programming Languages](projects/nested-languages.md) 32 | * [Newcomer metrics and gamification](projects/newcomer-metrics.md) 33 | * [Optimize Caching](projects/optimize-caching.md) 34 | * [Performance measurement for pull requests](projects/pr-perftest.md) 35 | * [One click linting for online projects in the browser](projects/roberta-external-source.md) 36 | * [Improve Sphinx support in rstcheck](projects/rstcheck-with-better-sphinx-support.md) 37 | 38 | #### Completed projects 39 | 40 | * [Implement Aspects Support](projects/aspects.md) 41 | * [Improve the coala CLI](projects/coala-cli.md) 42 | * [Improve coala website & supporting tools](projects/coala-web.md) 43 | * [cobot enhancement, testing and porting](projects/cobot-enhancement.md) 44 | * [Documentation Extraction and Parsing](projects/documentation-extraction.md) 45 | * [Enhance coala-quickstart](projects/enhance-coala-quickstart.md) 46 | * [Extend Linter Integration](projects/extend-linter-integration.md) 47 | * [Implement GitLab and Bitbucket Support for GitMate](projects/gitmate-gitlab.md) 48 | * [Convert Bears to Aspects](projects/implement-aspects.md) 49 | * [Vulture dead code removal](projects/vulture.md) 50 | -------------------------------------------------------------------------------- /data/locale/en/book.json: -------------------------------------------------------------------------------- 1 | { 2 | "root": "." 3 | } 4 | -------------------------------------------------------------------------------- /data/locale/en/faq: -------------------------------------------------------------------------------- 1 | ../../../_faq/ -------------------------------------------------------------------------------- /data/locale/en/projects: -------------------------------------------------------------------------------- 1 | ../../../_projects/ -------------------------------------------------------------------------------- /data/locale/hi/faq.json: -------------------------------------------------------------------------------- 1 | { 2 | "i-want-to-do-a-gsoc.md": "मैं GSoC करना चाहता हूँ", 3 | "gsoc-requirements.md": "GSoC में चयनित होने के लिए क्या आवश्यकताएं हैं?", 4 | "own-project-idea.md": "मेरे पास अपनी खुद के प्रोजैक्ट का विचार है! (छात्र तथा उपदेशक!)", 5 | "steal-project-idea.md": "यदि किसी व्यक्ति ने एक प्रोजैक्ट को सुलझाने के लिए मेरे अनूठे विचार को चुराया है तो क्या होगा?", 6 | "writing-a-great-proposal.md": "मैं एक अद्भुत प्रस्ताव पर कैसे काम करूं?", 7 | "is-mentor-necessary.md": "वेबसाइट पर एक शोकेस प्रोजेक्ट में कोई उपदेशक नहीं है, लेकिन मुझे उस प्रोजेक्ट में दिलचस्पी है?", 8 | "contact-mentor.md": "मुझे एक दिलचस्प परियोजना मिली! मैं अपने उपदेशक से कैसे संपर्क कर सकता हूं?", 9 | "working-out-the-proposal.md": "मुझे प्रस्ताव का काम कब से शुरू करना चाहिए?", 10 | "student-obligations.md": "GSoC के दौरान एक छात्र के रूप में मेरे दायित्व क्या हैं?", 11 | "mentor-obligations.md": "GSoC के दौरान एक उपदेशक के रूप में मेरे दायित्व क्या हैं?", 12 | "thesis.md": "मैं coala के साथ थीसिस लिखना चाहता हूं!", 13 | "application-template.md": "क्या आपके पास कोई एप्लिकेशन टेम्प्लेट है?", 14 | "project-participation.md": "क्या सभी सूचीबद्ध परियोजनाएं GSoC (या कोई अन्य पहल) का हिस्सा होगी?" 15 | } 16 | -------------------------------------------------------------------------------- /data/locale/id/README.md: -------------------------------------------------------------------------------- 1 | # Proyek 2 | 3 | -------------------------------------------------------------------------------- /data/locale/id/SUMMARY.md: -------------------------------------------------------------------------------- 1 | ### Google Summer of Code 2 | 3 | #### Proposed projects 4 | 5 | * [Linting dengan satu klik untuk proyek online di browser](projects/roberta_external_source.md) 6 | -------------------------------------------------------------------------------- /data/locale/id/book.json: -------------------------------------------------------------------------------- 1 | { 2 | "root": "." 3 | } 4 | -------------------------------------------------------------------------------- /data/locale/id/faq.json: -------------------------------------------------------------------------------- 1 | { 2 | "i_want_to_do_a_gsoc.md": "Saya ingin mengikuti GSoC!", 3 | "gsoc-requirements.md": "Apa yang dibutuhkan untuk diterima GSoC?", 4 | "own-project-idea.md": "Saya memiliki ide untuk sebuah proyek! (Mentor dan murid!)", 5 | "steal-project-idea.md": "Apa yang terjadi apabila seseorang mencuri ide unik saya untuk memecahakan sebuah proyek?", 6 | "writing-a-great-proposal.md": "Bagaimana cara membuat sebuah proposal yang baik?", 7 | "is-mentor-necessary.md": "Sebuah proyek yang dipamerkan tidak memiliki mentor, namun saya tertarik dengan proyek tersebut.", 8 | "contact-mentor.md": "Saya menemukan proyek hebat! Bagaimana saya menghubungi mentor saya?", 9 | "working-out-the-proposal.md": "Kapan sebaiknya saya menulis proposal?", 10 | "student-obligations.md": "Apa kewajiban saya sebagai murid saat menjalakan GSoC?", 11 | "mentor-obligations.md": "Apa kewajiban saya sebagai mentor saat menjalakan GSoC?", 12 | "thesis.md": "saya ingin menulis tesis bersama coala!", 13 | "application-template.md": "Apakah anda memiliki templat aplikasi?", 14 | "project-participation.md": "Apakah semua proyek yang terdaftar akan menjadi bagian dari GSoC (atau inisiasi lainnya)?" 15 | } 16 | -------------------------------------------------------------------------------- /data/locale/id/faq/coala-will-apply-for-gsoc.md: -------------------------------------------------------------------------------- 1 | --- 2 | pertanyaan: "Apakah coala akan berlaku untuk Google Summer of Code tahun depan?" 3 | --- 4 | Ya, coala akan berlaku sebagai organisasi untuk Google Summer of Code tahun depan. Anda dapat membaca [Timeline GSoC](https://developers.google.com/open-source/gsoc/timeline) untuk mendapatkan gambaran tentang bagaimana hal-hal akan berjalan. 5 | -------------------------------------------------------------------------------- /data/locale/id/faq/contact-mentor.md: -------------------------------------------------------------------------------- 1 | Hampir semua mentor aktif di [gitter](https://coala.io/chat) 2 | Cukup kirimi kami pesan! Sebagai tambahan, kebanyakan mentor punya 3 | alamat email yang terekspos di profil GitHub mereka. 4 | -------------------------------------------------------------------------------- /data/locale/id/projects.json: -------------------------------------------------------------------------------- 1 | { 2 | "roberta-external-source.md": { 3 | "name" : "Linting dengan satu klik untuk proyek online di browser", 4 | "desc" : "Buat sebuah loader untuk proyek-proyek dari sumber data remote yang bisa digunakan dari halaman web coala untuk menyediakan linting dalam satu klik untuk proyek-proyek online.", 5 | "requirements" : [ 6 | "Pelamar (applicant) sebaiknya terbiasa dengan pembuatan bear dan XML parsing menggunakan xpath atau bahasa query yang sejenis", 7 | "Pelamar sebaiknya terbiasa dengan codebase coala dan cara kerja dari REST APInya, termasuk otentikasi.", 8 | "Pelamar telah berkontribusi ke modul coala yang relevan, platform Open Roberta, atau keduanya." 9 | ], 10 | "difficulty" : "tinggi", 11 | "issues" : [ 12 | ] 13 | } 14 | } 15 | -------------------------------------------------------------------------------- /data/locale/id/projects/roberta-external-source.md: -------------------------------------------------------------------------------- 1 | Bagi anak-anak dan siswa, belajar program menjadi semakin mudah diakses 2 | melalui platform pemrograman seperti Open Roberta Lab dan Code.org, dll. 3 | Sementara platform ini menyediakan sumber daya dan lingkungan bagi pemula untuk menjelajah dan belajar, 4 | sifat browser-sentris dari latihan dan toolchain membuatnya sulit untuk mengambil konten, 5 | belajar tentang struktur proyek yang tepat, dan menggunakan alat pihak ketiga 6 | semakin banyak digunakan oleh developer, seperti static code analysis dan code generation. 7 | 8 | Proyek yang diusulkan ini adalah lebih ke tentang memuat sumber online 9 | daripada memasukkan file lokal ke one-click linter di homepage coala. 10 | Ini akan memberi siswa kesempatan untuk memeriksa gaya pengkodean dan sifat menarik lainnya 11 | dari proyek mereka di browser, tanpa melompat keluar lingkaran untuk mengambil pekerjaan mereka 12 | dari sumber jarak jauh, dan menginstal dan belajar menggunakan command line interface coala. 13 | 14 | [penerjemahan belum selesai] 15 | 16 | The project should allow, for example, for a student to load and check NEPO-programs from the 17 | Open Robert Lab directly from the browser. This can later be extended to 18 | allow for other remote sources, like code.org, 5code, or github/bitbucket projects 19 | to be checked according to the language hints provided by the respective APIs. 20 | 21 | Open Roberta is a platform for students of any age to program consumer-grade 22 | robotics-hardware in a visual manner, using a blockly-like language called `NEPO`. 23 | Roberta is a long established international project initiated by the Fraunhofer IAIS 24 | that aims at nurturing interest in STEM and robotics in young women and students. 25 | Using Open Roberta as an extensible platform instead of proprietary programmers 26 | specific to certain robotics hardware is an important part of Roberta's main goal 27 | of accessibility and outreach for young women and students of all ages. 28 | 29 | The student will work with members from the coala team, and members from 30 | Fraunhofer IAIS and other Roberta-related projects. The student may acquire 31 | additional certification through Fraunhofer IAIS in Sankt Augustin, Germany. 32 | 33 | #### Milestones 34 | 35 | ##### PREPARATION/BONDING 36 | 37 | * Familiarity with the OpenRoberta partner project is established and a method for external access is designed and implemented in a basic fashion 38 | * A design goal is reached with the coala project on how to integrate external data sources into the coala web page, including mock-ups and a prototype implementation for the UI 39 | 40 | ##### CODING PHASE 1 41 | 42 | * A bear for downloaded NEPO-programs is created that checks for certain simple properties of the program, like nesting depths and whether any part of the program tree is undefined. The specific properties shall be defined in the GSoC application. 43 | * The infrastructure for downloading external resources through the web interface is established and working in a basic fashion 44 | 45 | ##### CODING PHASE 2 46 | 47 | * A NEPO program stored on the Open Roberta Lab can be checked from the web interface 48 | * The infrastructure for downloading external resources through the web interface is well documented and loaders for other resource locations can easily be added 49 | * All necessary changes to the webpage UI are implemented 50 | 51 | ##### CODING PHASE 3 52 | 53 | * A NEPO program stored on the Open Roberta Lab can be checked from the web interface and a user receives useful advice about the quality of their project 54 | * A github repository can be checked from the web interface. A useful collection of bears is chosen using github's project language hints. 55 | -------------------------------------------------------------------------------- /data/locale/ro/faq.json: -------------------------------------------------------------------------------- 1 | { 2 | "i-want-to-do-a-gsoc.md": "Vreau sa particip la GSOC!", 3 | "gsoc-requirements.md": "Care sunt cerintele pentru a fi acceptat?", 4 | "own-project-idea.md": "Am o idee proprie pentru proiect! (Mentori si studenti!)", 5 | "steal-project-idea.md": "Ce se intampla daca cineva imi fura propria idee pentru rezolvarea proiectului?", 6 | "writing-a-great-proposal.md": "Cum pot sa scriu o propunere deosebita?", 7 | "is-mentor-necessary.md": "Prezentarea proiectului de pe site nu are mentori, dar sunt interesat de proiect?", 8 | "contact-mentor.md": "Am gasit un proiect interesant! Cum pot sa imi contactez mentorul?", 9 | "working-out-the-proposal.md": "Cand trebuie sa incep sa lucrez la propunerea mea?", 10 | "student-obligations.md": "Care sunt obligatiile mele ca student in timpul GSOC-ului?", 11 | "mentor-obligations.md": "Care sunt obligatiile mele ca mentor in timpul GSOC-ului?", 12 | "thesis.md": "Vreau sa scriu o teza cu coala!", 13 | "application-template.md": "Ai un sablon pentru aplicatie?", 14 | "project-participation.md": "Toate proiectele afisate o sa faca parte din GSOC (sau alte initiative)?" 15 | } 16 | -------------------------------------------------------------------------------- /data/projects.liquid: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | [ 4 | {% for post in site.projects %} 5 | { 6 | "name" : "{{ post.name }}", 7 | "desc" : "{{ post.desc }}", 8 | "requirements" : [{% for req in post.requirements %}"{{ req }}"{% unless forloop.last %},{% endunless %} 9 | {% endfor %}], 10 | "difficulty" : "{{ post.difficulty }}", 11 | "issues" : [{% for post in post.issues %}"{{ post }}"{% unless forloop.last %},{% endunless %} 12 | {% endfor %}], 13 | "mentors" : [{% for mentor in post.mentors %}"{{ mentor }}" {% unless forloop.last %},{% endunless %}{% endfor %}], 14 | "initiatives" : [{% for initiative in post.initiatives %} "{{ initiative }}" {% unless forloop.last %},{% endunless %}{% endfor %}], 15 | "tags" : [{% for tag in post.tags %} "{{ tag }}"{% unless forloop.last %},{% endunless %}{% endfor %}], 16 | "collaborating_projects" : [{% for cp in post.collaborating_projects %}"{{ cp }}"{% unless forloop.last %},{% endunless %}{% endfor %}], 17 | "content_url" : "{{post.url}}", 18 | "path" : "{{post.path}}", 19 | "status" : [{% for status in post.status %} "{{ status }}" {% unless forloop.last %},{% endunless %}{% endfor %}], 20 | "markdown" : "{{post.path | replace: '_projects/',''}}" 21 | }{% unless forloop.last %},{% endunless %}{% endfor %} 22 | ] 23 | -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/favicon.ico -------------------------------------------------------------------------------- /netlify.toml: -------------------------------------------------------------------------------- 1 | [build] 2 | publish = "_site" 3 | command = "gem install bundler && .ci/build.sh" 4 | -------------------------------------------------------------------------------- /partials/tabs/faq.html: -------------------------------------------------------------------------------- 1 | 2 |
3 |
    4 |
  • 5 |
    6 |

    7 |
    8 |
    9 |

    10 |
    11 |
  • 12 |
13 |
14 | 20 | -------------------------------------------------------------------------------- /partials/tabs/mentors.html: -------------------------------------------------------------------------------- 1 | 2 |
3 |
4 |
5 |

Hello there!

6 |

7 | We are the mentors for coala in GSoC 2019. 8 |

9 |

10 | Just drop a message on Gitter - 11 | we'd love to help you personally. 12 |

13 |
14 |
15 |
16 |
17 | 37 |
38 |
39 |
40 |
41 |
42 |
43 |

Admins

44 |

45 | We are the admins for coala in GSoC 2019. 46 |

47 |

48 | Just drop a message on Gitter 49 |

50 |
51 |
52 |
53 |
54 | 74 |
75 | -------------------------------------------------------------------------------- /partials/tabs/students.html: -------------------------------------------------------------------------------- 1 | --- 2 | title: coala GSoC Projects Report 3 | --- 4 | 5 |
6 |
7 |
8 |

Hello World!

9 |

10 | The students who've participted in Google Summer of Code with {{ site.organization }} 11 |

12 |
13 |
14 |
15 |
16 | {% assign reportsByYear = site.reports | group_by_exp:"report", "report.date | date: '%y'" %} 17 |
18 |
19 | 24 |
25 | {% for year in reportsByYear reversed %} 26 |
27 |
28 |
29 |
30 |
31 |
32 | {% for report in year.items %} 33 | 46 | {% endfor %} 47 |
48 |
49 |
50 |
51 |
52 |
53 | {% endfor %} 54 |
55 |
56 | 61 | -------------------------------------------------------------------------------- /reports.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 12 | 13 | -------------------------------------------------------------------------------- /resources/css/404.css: -------------------------------------------------------------------------------- 1 | html, body { 2 | height: 100%; 3 | margin: 0; 4 | overflow-x: hidden; 5 | padding: 0; 6 | width: 100%; 7 | } 8 | main { 9 | align-items: center; 10 | background-color: #fafafa; 11 | display: flex; 12 | flex-direction: row; 13 | justify-content: center; 14 | } 15 | main .container { 16 | padding: 3% 5%; 17 | } 18 | .error { 19 | font-family: "Open Sans","Helvetica Neue",Helvetica,Roboto,Arial,sans-serif; 20 | margin-left: -12.5%; 21 | } 22 | .error .message { 23 | color: #004D40; 24 | display: block; 25 | font-size: 4.5vw; 26 | font-weight: bold; 27 | } 28 | .error p { 29 | font-size: 2vw; 30 | font-weight: 200; 31 | } 32 | .error p span { 33 | font-weight: 400; 34 | } 35 | .error .home { 36 | text-transform: uppercase; 37 | } 38 | .error .buttons { 39 | padding: 3%; 40 | } 41 | .coala-book { 42 | opacity: 0.85; 43 | text-align: center; 44 | } 45 | .coala-book img { 46 | width: 80%; 47 | } 48 | @media only screen and (max-width:760px) { 49 | main { 50 | flex-direction: column; 51 | } 52 | .error { 53 | margin-left: auto; 54 | text-align: center; 55 | } 56 | .error p { 57 | font-size: 3.5vw; 58 | } 59 | .coala-book img { 60 | width: 100%; 61 | } 62 | } 63 | -------------------------------------------------------------------------------- /resources/css/style.css: -------------------------------------------------------------------------------- 1 | .all-filters-option { /* Ignore CSSLintBear */ 2 | animation-duration: 1s; 3 | animation-fill-mode: both; 4 | background-color: white; 5 | border-radius: 20px; 6 | box-shadow: 0 0 15px 2px black; 7 | margin: 10px 0; 8 | min-width: 350px; 9 | position: relative; 10 | z-index: 1002; 11 | -webkit-animation-duration: 1s; 12 | -webkit-animation-fill-mode: both; 13 | } 14 | .apply-flex { 15 | align-items: center; 16 | display: flex; 17 | flex-flow: row wrap; 18 | } 19 | .break-word { 20 | word-wrap: break-word; 21 | } 22 | .center-content { 23 | justify-content: center; 24 | } 25 | .close-filters { 26 | margin-top: 1.25rem; 27 | position: absolute; 28 | right: 6%; 29 | z-index: 1003; 30 | } 31 | .display-none { 32 | display: none; 33 | } 34 | .evenly-spread-content { 35 | justify-content: space-evenly; /* Ignore CSSLintBear */ 36 | } 37 | .hash_value_dup { 38 | left: -9999px; 39 | position: absolute; 40 | } 41 | .hinttext { 42 | background-color: gray; 43 | border-radius: 6px; 44 | color: #fff; 45 | left: 60%; 46 | margin-left: -60px; 47 | padding: 5px 0; 48 | position: absolute; 49 | text-align: center; 50 | top: 95%; 51 | visibility: hidden; 52 | width: 120px; 53 | z-index: 1; 54 | } 55 | .hinttext::after { 56 | border-color: transparent transparent gray transparent; 57 | border-style: solid; 58 | border-width: 5px; 59 | bottom: 100%; 60 | content: " "; 61 | left: 50%; 62 | margin-left: -5px; 63 | position: absolute; 64 | } 65 | .fa-clipboard:hover { 66 | cursor: pointer; 67 | } 68 | .fa-clipboard:hover .hinttext { 69 | visibility: visible; 70 | } 71 | .filter-projects-inputs { 72 | display: flex; 73 | flex-flow: row wrap; 74 | justify-content: space-evenly; /* Ignore CSSLintBear */ 75 | margin-top: 1rem; 76 | } 77 | .filter-btn { 78 | width: 165px; 79 | z-index: 0; 80 | } 81 | .filter-btn .btn-large { 82 | border-radius: 100px; 83 | box-shadow: 0 0 10px 1px darkslategray; 84 | } 85 | .filters-btns { 86 | width: 50%; 87 | } 88 | .filters-inputs { 89 | justify-content: space-around; 90 | padding: 20px 0; 91 | } 92 | .filter-select-fields { 93 | justify-content: space-around; 94 | padding-bottom: 10px; 95 | padding-top: 20px; 96 | width: 100%; 97 | } 98 | .footer-icons { 99 | display: flex; 100 | flex-wrap: wrap; 101 | justify-content: space-evenly; /* Ignore CSSLintBear */ 102 | line-height: 3em; 103 | } 104 | .gsoc-students { 105 | margin-top: 1em; 106 | } 107 | .icon { 108 | color: white; 109 | } 110 | .fa { 111 | cursor: pointer; 112 | } 113 | .justify-text { 114 | text-align: justify; 115 | } 116 | nav { 117 | background-color: #37474f; 118 | } 119 | .nav-logo { 120 | width: 50px; 121 | } 122 | .project-detail-element > .clickable:hover, .clickable:hover .chip:hover { 123 | background-color: #f3f5f8; 124 | cursor: pointer; 125 | } 126 | .report .card { 127 | box-shadow: 0 1px 1px 0 rgba(0, 0, 0, 0.0), 0 1px 1px 0 rgba(0, 0, 0, 0.0), 0 1px 1px 0 rgba(0, 0, 0, 0.05); 128 | margin-bottom: 0; 129 | } 130 | .report { 131 | background-color: #f3f5f8; 132 | } 133 | .report .card .card-content { 134 | padding: 12px; 135 | } 136 | .report .link { 137 | padding: 0.5em; 138 | } 139 | .tab { 140 | cursor: pointer; 141 | } 142 | .report .fullh { 143 | height: 100%; 144 | } 145 | .report .blog-title { 146 | font-weight: 500; 147 | letter-spacing: 0.1em; 148 | text-align: center; 149 | } 150 | .report .links-section a { 151 | color: lightslategray; 152 | padding: 0.1em; 153 | text-decoration: none; 154 | } 155 | .report .row { 156 | display: -webkit-box; 157 | display: -webkit-flex; 158 | display: -ms-flexbox; 159 | display: flex; 160 | flex-wrap: wrap; 161 | } 162 | .report .row > [class*='col'] { /* Ignore CSSLintBear */ 163 | display: flex; 164 | flex-direction: column; 165 | } 166 | .report .flex1 { 167 | flex: 1; 168 | } 169 | .report .activity { 170 | white-space: pre; 171 | } 172 | .report .fl { 173 | background: lightcyan; 174 | text-align: center; 175 | } 176 | .report .card { 177 | word-break: break-word; /* Ignore CSSLintBear */ 178 | } 179 | .report td p { 180 | display: inline; 181 | } 182 | .report .padding-table tbody tr { 183 | border-bottom: 1px solid aliceblue; 184 | } 185 | .report-url a { 186 | color: #f57f17; 187 | } 188 | @media only screen and (min-width: 993px) { 189 | .container { 190 | width: 90%; 191 | } 192 | .for-mobile { 193 | display: none; 194 | } 195 | } 196 | @media only screen and (max-width: 992px) { 197 | .for-non-mobile { 198 | display: none; 199 | } 200 | } 201 | .searchbar { 202 | margin-top: 0; 203 | min-width: 340px; 204 | width: 85%; 205 | } 206 | .sha256sum_hash { 207 | display: flex; 208 | justify-content: space-evenly; /* Ignore CSSLintBear */ 209 | } 210 | .students { 211 | padding: 0 20px; 212 | } 213 | .theatre .name { 214 | padding-left: 0.5em; 215 | padding-right: 0.5em; 216 | } 217 | .sha256sum_hash_value { 218 | word-wrap: break-word; 219 | } 220 | @-webkit-keyframes fade-in { 221 | 0% {opacity: 0;} 222 | 100% {opacity: 1;} 223 | } 224 | @keyframes fade-in { 225 | 0% {opacity: 0;} 226 | 100% {opacity: 1;} 227 | } 228 | .fade-in { 229 | -webkit-animation-name: fade-in; 230 | animation-name: fade-in; 231 | } 232 | -------------------------------------------------------------------------------- /resources/images/coala-404.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/resources/images/coala-404.png -------------------------------------------------------------------------------- /resources/images/coala.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/resources/images/coala.png -------------------------------------------------------------------------------- /resources/js/analytics.js: -------------------------------------------------------------------------------- 1 | (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ 2 | (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), 3 | m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) 4 | })(window,document,'script','https://www.google-analytics.com/analytics.js','ga'); 5 | 6 | ga('create', 'UA-76769778-4', 'auto'); 7 | ga('send', 'pageview'); 8 | -------------------------------------------------------------------------------- /resources/js/app.js: -------------------------------------------------------------------------------- 1 | (function(){ 2 | var app = angular.module('coala', ['ngSanitize','btford.markdown', 'ngRoute']); 3 | 4 | app.factory('Languages', function ($location) { 5 | langs = [{ 6 | 'name' : 'English', 7 | 'code' : 'en' 8 | }, 9 | { 10 | 'name' : 'Bahasa', 11 | 'code' : 'id' 12 | }, 13 | { 14 | 'name' : 'हिन्दी', 15 | 'code' : 'hi' 16 | }, 17 | { 18 | 'name' : 'Romanian', 19 | 'code' : 'ro' 20 | }]; 21 | selected_language = JSON.parse(window.localStorage.getItem('lang')) || langs[0]; 22 | 23 | return { 24 | setData: function (val) { 25 | angular.forEach(langs, function(v, k){ 26 | if (v.code == val){ 27 | window.localStorage.setItem('lang', JSON.stringify(v)); 28 | selected_language = v; 29 | } 30 | }); 31 | }, 32 | getData: function () { 33 | return selected_language['code']; 34 | 35 | }, 36 | getAllLanguages: function () { 37 | return langs; 38 | }, 39 | getLanguageObject: function () { 40 | return selected_language; 41 | } 42 | } 43 | }); 44 | 45 | app.config(['$routeProvider', 46 | function($routeProvider) { 47 | $routeProvider. 48 | when('/projects', { 49 | template: '', 50 | reloadOnSearch: false 51 | }). 52 | when('/mentors', { 53 | template: '' 54 | }). 55 | when('/faq', { 56 | template: '' 57 | }). 58 | when('/students', { 59 | template: '' 60 | }). 61 | otherwise({ 62 | redirectTo: '/projects' 63 | }); 64 | }]); 65 | 66 | app.controller('LanguageController', function ($scope, Languages) { 67 | $scope.langs = Languages.getAllLanguages(); 68 | $scope.update = function () { 69 | Languages.setData($scope.language.code); 70 | } 71 | $scope.init_language = Languages.getLanguageObject(); 72 | $scope.getLanguage = function () { 73 | $scope.init_language = Languages.getLanguageObject(); 74 | $(document).ready(function(){ 75 | $('select').material_select(); 76 | }) 77 | $scope.$evalAsync(); 78 | return $scope.init_language; 79 | } 80 | }) 81 | 82 | app.controller('NavController', function ($location) { 83 | this.view = $location.path() 84 | this.setView = function (stab) { 85 | this.view = stab 86 | $location.path(stab); 87 | } 88 | this.isSet = function (stab) { 89 | return $location.path() == stab 90 | } 91 | }) 92 | 93 | app.filter('format_issue', function () { 94 | return function (value) { 95 | if (!value) return ''; 96 | res = value.split('/'); 97 | last = res.length - 1; 98 | return res.slice(3, last - 1).join('/') + '#' + res[last]; 99 | }; 100 | }); 101 | 102 | })(); 103 | -------------------------------------------------------------------------------- /resources/js/directives/faqs.js: -------------------------------------------------------------------------------- 1 | angular.module('coala') 2 | .directive('faq', ['$http', '$templateCache', function ($http, $templateCache, Languages) { 3 | return { 4 | restrict: 'E', 5 | templateUrl: '/partials/tabs/faq.html', 6 | controller: function ($scope, Languages) { 7 | $scope.lang = Languages.getData(); 8 | 9 | $scope.getDefaultFAQMetadata = function () { 10 | $http.get('data/faq.liquid') 11 | .then(function (res) { 12 | $scope.faqs = res.data; 13 | $scope.generateMarkdown(); 14 | }) 15 | } 16 | 17 | $scope.lang = Languages.getData(); 18 | 19 | $scope.getDefaultFAQMetadata(); 20 | 21 | $scope.$watch(function () { 22 | return Languages.getData(); 23 | }, function () { 24 | $scope.setLanguage(Languages.getData()); 25 | }, true); 26 | 27 | 28 | $scope.setLanguage = function (val) { 29 | $scope.lang = val; 30 | $scope.updateFAQ(); 31 | } 32 | 33 | $scope.updateFAQ = function () { 34 | if ($scope.lang != 'en') { 35 | 36 | $http.get('data/locale/' + $scope.lang + '/faq.json') 37 | .then(function (res) { 38 | $scope.faqs.map(function (faq) { 39 | if (res.data[faq.markdown]) { 40 | Object.keys(faq).map(function (key) { 41 | if (res.data[faq.markdown]) { 42 | faq['question'] = res.data[faq.markdown] 43 | 44 | } 45 | }); 46 | } 47 | }); 48 | $scope.generateMarkdown(); 49 | }); 50 | } else { 51 | $scope.getDefaultFAQMetadata(); 52 | } 53 | } 54 | 55 | $scope.generateMarkdown = function () { 56 | 57 | if ($scope.lang != 'en') { 58 | $scope.faqs.forEach(function (faq, key) { 59 | $http.get('data/locale/' + $scope.lang + '/faq/' + faq.markdown) 60 | .then(function (res) { 61 | $scope.faqs[key].answer = res.data 62 | }, function (error) { 63 | $http.get($scope.faqs[key].url) 64 | .then(function (res) { 65 | $scope.faqs[key].answer = res.data; 66 | }) 67 | }); 68 | }) 69 | } else { 70 | $scope.faqs.forEach(function (f, k) { 71 | $http.get($scope.faqs[k].url) 72 | .then(function (res) { 73 | $scope.faqs[k].answer = res.data 74 | }); 75 | }) 76 | } 77 | } 78 | 79 | }, 80 | controllerAs: 'toc' 81 | } 82 | }]); 83 | -------------------------------------------------------------------------------- /resources/js/directives/mentors.js: -------------------------------------------------------------------------------- 1 | angular.module('coala') 2 | .directive('mentors', ['$http', function ($http) { 3 | return { 4 | restrict: 'E', 5 | templateUrl: '/partials/tabs/mentors.html', 6 | controller: function ($scope, $rootScope) { 7 | self = this 8 | self.mentorsList = {} 9 | self.adminsList = {} 10 | 11 | $http.get('data/projects.liquid') 12 | .then(function (res) { 13 | $scope.projects = res.data.filter(project => project.initiatives.includes("GSoC19")) 14 | angular.forEach($scope.projects, function (value, key) { 15 | angular.forEach(value.mentors, function (value, key) { 16 | self.mentorsList[value] = { 17 | "github_handle": value, 18 | "github_avatar_url": "https://avatars.githubusercontent.com/" + value 19 | } 20 | }); 21 | }); 22 | }) 23 | 24 | $http.get('data/admins.json') 25 | .then(function (res) { 26 | admins = res.data 27 | angular.forEach(admins, function (value, key) { 28 | self.adminsList[value] = { 29 | "github_handle": value, 30 | "github_avatar_url": "https://avatars.githubusercontent.com/" + value 31 | 32 | } 33 | }); 34 | }) 35 | 36 | }, 37 | controllerAs: "gic" 38 | } 39 | }]); 40 | -------------------------------------------------------------------------------- /resources/js/directives/students.js: -------------------------------------------------------------------------------- 1 | angular.module('coala') 2 | .directive('students', ['$http', function ($http) { 3 | return { 4 | restrict: 'E', 5 | templateUrl: '/partials/tabs/students.html', 6 | controller: function ($scope, $rootScope) { }, 7 | controllerAs: "gsoc" 8 | } 9 | }]); 10 | -------------------------------------------------------------------------------- /resources/vendors/markdown/markdown.js: -------------------------------------------------------------------------------- 1 | /* 2 | * angular-markdown-directive v0.3.1 3 | * (c) 2013-2014 Brian Ford http://briantford.com 4 | * License: MIT 5 | */ 6 | 7 | 'use strict'; 8 | 9 | angular.module('btford.markdown', ['ngSanitize']). 10 | provider('markdownConverter', function () { 11 | var opts = {}; 12 | return { 13 | config: function (newOpts) { 14 | opts = newOpts; 15 | }, 16 | $get: function () { 17 | return new Showdown.converter(opts); 18 | } 19 | }; 20 | }). 21 | directive('btfMarkdown', ['$sanitize', 'markdownConverter', function ($sanitize, markdownConverter) { 22 | return { 23 | restrict: 'AE', 24 | link: function (scope, element, attrs) { 25 | if (attrs.btfMarkdown) { 26 | scope.$watch(attrs.btfMarkdown, function (newVal) { 27 | var html = newVal ? $sanitize(markdownConverter.makeHtml(newVal)) : ''; 28 | element.html(html); 29 | }); 30 | } else { 31 | var html = $sanitize(markdownConverter.makeHtml(element.text())); 32 | element.html(html); 33 | } 34 | } 35 | }; 36 | }]); 37 | -------------------------------------------------------------------------------- /screenshots/header.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/screenshots/header.png -------------------------------------------------------------------------------- /screenshots/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/coala/projects/eda572a26251957eb9ddfe985c0d628bfb24b6aa/screenshots/logo.png -------------------------------------------------------------------------------- /tools/authorPatchCollector.py: -------------------------------------------------------------------------------- 1 | import argparse 2 | import git 3 | import os 4 | import subprocess 5 | 6 | 7 | def make_new_dir(dir_path): 8 | if os.path.isdir(dir_path): 9 | print(f'{dir_path} already exists. Making patches ...') 10 | else: 11 | os.mkdir(dir_path) 12 | print(f'{dir_path} successfully created. Making patches ...') 13 | 14 | 15 | def is_git_repo(path): 16 | try: 17 | _ = git.Repo(path).git_dir 18 | return True 19 | except git.exc.InvalidGitRepositoryError: 20 | return False 21 | 22 | 23 | def patch_collector(dir_path, authors, output): 24 | 25 | if(is_git_repo(dir_path) is False): 26 | print(f'\n{dir_path} is not a git directory.\n') 27 | return 28 | 29 | print(f'\n**Inside {dir_path}**\n') 30 | end_hash = '' 31 | begin_hash = '' 32 | patch_count = 1 33 | range_count = 1 34 | 35 | author_list = '' 36 | for author in authors: 37 | author_list += f'--author={author} ' 38 | 39 | get_hashes_cmd = (f'git -C {dir_path} log --pretty=format:"%h" ' 40 | f'{author_list}') 41 | commit_hashes = subprocess.check_output(get_hashes_cmd, shell=True) 42 | commit_hashes = commit_hashes.decode(encoding='utf-8') 43 | commit_hashes = commit_hashes.split('\n') 44 | 45 | for commit_hash in commit_hashes: 46 | 47 | ancestor_hash_cmd = (f'git -C {dir_path} log --pretty=format:"%h" ' 48 | f'{author_list}{commit_hash}^^..{commit_hash}^ ' 49 | '--exit-code 1>/dev/null') 50 | 51 | if subprocess.Popen(ancestor_hash_cmd, shell=True).wait(): 52 | if end_hash == '': 53 | end_hash = commit_hash 54 | begin_hash = commit_hash 55 | range_count = range_count + 1 56 | 57 | else: 58 | subdir_msg = ('\nPlease enter a subdirectory name for this patch' 59 | '(leave this empty\nto leave this patch out, use ./ ' 60 | 'for the root directory):') 61 | print('\n') 62 | 63 | if end_hash == '': 64 | temp = patch_count-1 65 | print(f'Adding one patch to {temp} existing:') 66 | subprocess.Popen( 67 | f'git -C {dir_path} log {commit_hash}^..{commit_hash}', 68 | shell=True).wait() 69 | print(subdir_msg) 70 | subdir = input() 71 | 72 | if subdir != '': 73 | newdir = f'{output}/{subdir}' 74 | print(f'mkdir -p {newdir}') 75 | make_new_dir(newdir) 76 | subprocess.Popen( 77 | f'git -C {dir_path} format-patch {commit_hash}^..' 78 | f'{commit_hash} -o {newdir}', shell=True).wait() 79 | patch_count = patch_count + 1 80 | 81 | else: 82 | print('Omitting patch...') 83 | 84 | else: 85 | temp = patch_count-1 86 | print(f'Adding {range_count} patches to {temp} existing:') 87 | subprocess.Popen( 88 | f'git -C {dir_path} log {begin_hash}^^..{end_hash} ' 89 | f'--oneline', shell=True).wait() 90 | print(subdir_msg) 91 | subdir = input() 92 | 93 | if subdir != '': 94 | newdir = f'{output}/{subdir}' 95 | print(f'mkdir -p {newdir}') 96 | make_new_dir(newdir) 97 | subprocess.Popen( 98 | f'git -C {dir_path} format-patch {begin_hash}^^..' 99 | f'{end_hash} -o {newdir}', shell=True).wait() 100 | patch_count = patch_count + range_count 101 | 102 | else: 103 | print('Omitting patch series...') 104 | 105 | end_hash = '' 106 | range_count = 1 107 | 108 | 109 | def main(): 110 | help_message = '''This is a simple helper script that allows collecting all 111 | patches from one author in a git repository. It will detect consequent 112 | ranges of patches and ask for each range for a subdirectory so you can 113 | distinguish the patch series.''' 114 | 115 | parser = argparse.ArgumentParser(description=help_message) 116 | parser.add_argument('-a', '--author', action='append', required=True, 117 | help="Name of contributor") 118 | parser.add_argument('-o', '--opdir', required=True, 119 | help='Output directory absolute path.') 120 | parser.add_argument('-i', '--inpdir', action='append', required=True, 121 | help="Input directory path") 122 | args = parser.parse_args() 123 | authors = args.author 124 | output = args.opdir 125 | input_dir_paths = args.inpdir 126 | 127 | for input_path in input_dir_paths: 128 | patch_collector(input_path, authors, output) 129 | 130 | 131 | if __name__ == '__main__': 132 | main() 133 | --------------------------------------------------------------------------------