Tldr: Participate in Google Code-in under the umbrella of Coala

[waldyrious]

@jayvdb suggested in Gitter that the tldr project could be a good project for Google Code-in tasks. The next edition should start at the end of November. For a first experiment, we might consider joining under the umbrella of the Coala project (with which @jayvdb is involved, I believe).

For starters, I'll add in a comment below (to avoid making this one too long) a list of linter tools that can be covered in this project.

Next steps:

• Check the entries in the list below that already have a tldr page
  
  
  
  • Also add links to the tldr pages, for convenience
  
  
• Add links to the manpage and/or online help/documentation (preferably in example form)
• Decide if we want to create a separate issue for each command, and perhaps use a project board to keep track of them. Thoughts, @agnivade, @sbrl?
• Define further tasks to be done (@jayvdb?)

[waldyrious]

List of linter tools, provided by @jayvdb:

• [ ] apertium_lint
• [ ] astyle
• [x] cppcheck
• [ ] cppclean
• [ ] cpplint
• [ ] flawfinder
• [ ] mcs
• [ ] indent
• [ ] cmakelint
• [ ] coffeelint
• [ ] dockerfile_lint
• [ ] puppet-lint
• [ ] tomlv
• [ ] postcss
• [ ] csscomb
• [ ] csslint
• [ ] stylelint
• [ ] csvlint
• [ ] dartanalyzer
• [ ] elm-format
• [ ] licensecheck
• [ ] textlint
• [ ] dennis-cmd
• [ ] errcheck
• [ ] goimports
• [ ] golint
• [ ] goreturns
• [ ] gotype
• [x] go
• [ ] gofmt
• [ ] ghc-mod
• [ ] hlint
• [ ] bootlint
• [ ] httpolice
• [x] java
• [ ] infer
• [ ] eslint
• [ ] happiness
• [ ] cr
• [ ] jshint
• [ ] standard
• [ ] julia
• [ ] chktex
• [ ] luacheck
• [ ] remark
• [ ] alex
• [ ] proselint
• [ ] scspell
• [ ] write-good
• [ ] perlcritic
• [ ] phpcs
• [ ] php
• [ ] phpmd
• [ ] pug-lint
• [ ] bandit
• [ ] pydocstyle
• [ ] pyflakes
• [ ] pylint
• [ ] pycodestyle
• [ ] Rscript
• [ ] Rscript
• [ ] rstcheck
• [ ] rubocop
• [ ] reek
• [ ] ruby
• [x] java
• [ ] scss-lint
• [ ] shellcheck
• [ ] sqlint
• [ ] stylint
• [ ] tailor
• [ ] tslint
• [ ] verilator
• [x] perl
• [ ] vint
• [x] xmllint
• [ ] ramllint
• [ ] travis
• [ ] yamllint

[jayvdb]

cc @sils @yukiisbored

[sils]

Let me know how I can help with this, I'm very happy about those kinds of cooperations :) A tldr page for coala itself might be a good task in addition as well.

[jayvdb]

Recommend finishing https://github.com/tldr-pages/tldr/issues/1076 quickly, otherwise the problem will grow uncontrollably during gci.

[waldyrious]

@jayvdb that's not a problem, actually :) we currently only merge PRs when the author has signed the CLA, which was written specifically to avoid the bureaucratic nightmare should the project choose to adopt a different license (e.g. precisely the use case of #1076).

[agnivade]

Decide if we want to create a separate issue for each command, and perhaps use a project board to keep track of them. Thoughts, @agnivade, @sbrl?

A project board is fine. I think we decided to submit around 5 tasks right ? So does that mean we should narrow down to 5 tools which don't have a page yet ?

[sbrl]

@agnivade If we're documenting linters and we can only pick 5, then perhaps we could choose the 5 most popular languages' linters?

Also a project board would work just fine. Does that mean that they would be tagged with a label?

[agnivade]

@agnivade If we're documenting linters and we can only pick 5, then perhaps we could choose the 5 most popular languages' linters?

Sure

Does that mean that they would be tagged with a label?

No, in that case, they need to be issues. However, if we shortlist just 5. I think we can create issues and label them as gci.

[waldyrious]

@jayvdb, @sils, @yukiisbored: if we're going to pick 5 linters only, which ones would you suggest?

[agnivade]

ping @jayvdb , @sils , @yukiisbored

[yukiisbored]

@waldyrious I think it's better to make the student choose the linters so it'll be a reproducible task

[sils]

Agree with @yukiisbored make it part of the task to search the issue database, find out if somebody is already working on a linter and file and issue about it if it doesn't exist, get an assignment. That's the open source contribution path that they have to learn as well right?

[agnivade]

The problem might be that every student might choose a different linter and now we have 20-30 separate tasks being worked on.

[sils]

Yes, if you have lots of students you don't want them to redo the same task again wasting their time, no? With the assignments you can easily scale and even give them a title scheme so you can filter and manage all issues of that kind, see who's working on what, encourage them to review each other even.

[agnivade]

The concern was that we (atleast I) might not have the bandwidth to review 20-30 separate commands.

And I believe @jayvdb mentioned that it might be good to have students work on the same pages, that way we can make the task of completing a particular page to be reproducible.

Let me know your thoughts.

[sils]

What I've learned from @jayvdb last year is that the key is to have really
really well defined tasks that they can work on with almost no interaction.
At coala we even had them self assign issues with a bot, i.e. automating as
much as possible and letting people start on their own and also review each
other so they can do iterations with maintainers looking at higher grade
PRs due to that.

[sbrl]

I've got the bandwidth (esp. since I'll be spending a lot of time at uni :stuck_out_tongue:) - it's just the time that is limited on my end.

[waldyrious]

make it part of the task to search the issue database

Do you mean the tldr-pages' issue database? That means we first need to create issues for each of the linters listed here, right? That would answer one of the questions of the opening comment, but we need to figure out the others as well:

• Check the entries in the list of linters that already have a tldr page
  
  
  
  • Also add links to the tldr pages, for convenience
  
  
• Add links to the manpage and/or online help/documentation (preferably in example form)
• Decide if we want to create a separate issue for each command, and perhaps use a project board to keep track of them. Thoughts, @agnivade, @sbrl?
• Define further tasks to be done (@jayvdb?)

[waldyrious]

By the way, the 2017 edition has been announced in the Google Open Source Blog: Announcing Google Code-in 2017: The Latest and Greatest for Year Eight. Relevant quote:

Open source organizations can apply to participate in Google Code-in starting on Monday, October 9, 2017. Google Code-in starts for students November 28th!

[agnivade]

but we need to figure out the others as well:

All this would not be required if we can just decide on 5 linters. Then we can add the man page links, create issues (maybe create a project board for GCI) and be done with it. But I see there is a bit of indecision on how to go forward.

the 2017 edition has been announced

alright ! its happening !

[jayvdb]

Sorry for causing some confusion here and then running away.
I'm not sure where the idea of students working on the same page came from; that will cause problems, and is actually something to avoid.

Ideally you have a list of all possible linters, starting with linters coala supports , and students are assigned to one of them.

That way you have only one 'task' description, but and it can be repeated 99 times by 99 different students.

Two 'easy' approaches:

1. Create issues in advance for all linters to be included in GCI, and then the students can be given a issue search URL that excludes issues that are assigned
2. Create a wiki page (or similar) with all linters to be included in GCI, and have the students create the issue and then be assigned to the issue, and then strikethrough the entry in the wiki page, and request that the students search the issues before creating an issue (in case the strikethrough hasnt been done)

A better approach is to build a dynamic list app, which does (2) above, flawlessly, every time ;-) That also means the issue assignment can be done by the app with increased rights to assign issues and edit wikis, so you do not need to give those rights to newbies who are also minors.

[sbrl]

I'm sure we might be able to write a script that auto-assigns pre-existing issues to people, say, if they left a comment saying something like

@tldr-bot, I'd like to work on this issue please.

[agnivade]

The 2nd approach is better but error prone. Because you would be making the wiki page editable by students. About creating an app to automate that or adding new features to tldr-bot, I don't know who will work on it. I will not be able to allocate time to do something like that.

I think safest bet is with 1st approach, each of us can divide 5 issues amongst us. That gives us 15 issues (Feel free to take more). Slap a label on each issue, and create a filter query to get only unassigned issues.

[yukiisbored]

@sbrl You can use our corobo bot to do that ;) github.com/coala/corobo

[waldyrious]

@sbrl just so we're all in the same page, are you planning to implement (2) using the corobo bot?

[sbrl]

@waldyrious I wouldn't be averse to collaborating with someone with more python experience than I in testing it on my server without docker.

[sbrl]

I've got a bit of spare time, so I've investigated corobo - and I've got a few questions:

1. If it's a project under the coala organisation, won't coala be using this? In that case, couldn't we use their instance?
2. Does it work with virtualenv?
3. Should the COBOT_ROOT env variable point to the corobo repo itself (https://github.com/coala/corobo), or the repo you want it to operate on?
4. What's this "answers microservice"?
5. How do you interact with this bot? By commenting on an issue / pull request?

[yukiisbored]

@sbrl

1. Yes we're using it, but due to how it's written it can only see the coala organization and nothing else.
2. Yes, but we recommend using Docker since that's how we distributed tested builds.
3. COBOT_ROOT is set to the location of the folder where corobo is located
4. It's our attempt to answer questions in a natural language fashion.
5. You use it via chat like Gitter, Telegram, etc. But atm it only works best on Gitter.

[yukiisbored]

If you need any help deploying corobo to your server, Feel free to contact me via Gitter or email.

[agnivade]

Closing this now as GCI is over.