Style guide

We follow the meteor style guide.

Please read the meteor style guide before making any significant contribution.

Tips for new developers

Getting Started

• Install Wekan from source with rebuild-wekan.sh script, with options 1 to install dependencies and 2 to rebuild source, to your Linux computer (Debian 9 or Ubuntu 14.04 or newer), or try installing it via the virtual appliance
• You can use for example Visual Studio Code for editing code, it has Meteor.js etc plugins
• When changing database schema, migrations can be used.
• Excellent example how pull requests are improved and integrated, and not needed commits removed
• Ask questions at
  • We used to be at Rocket.Chat but that's been discontinued.
• You can ask anything, we are here to help. But also consult the sources that are already available.
  • Look through old pull requests
  • Read Wekan source code, you can use some git history viewer GUI like gitk
  • Read Meteor documentation for Meteor version in use, other versions mentioned at Dockerfile
• Docker up-to-date way: You can clone wekan/wekan repo and update docker-compose.yml file ROOT_URL etc as documented at https://github.com/wekan/wekan-mongodb commented docker-compose.yml file, install docker, and build from source with docker with "docker-compose up -d --build"
• Docker not up-to-date way: Docker environment for Wekan development.

Pull Request Workflow (Please read before submitting PR's)

• If package is available on meteor https://atmospherejs.com meteor add packagename or https://www.npmjs.com meteor npm install packagename then it's enough to add package that way, and there is no need to clone repo in rebuild-wekan.sh script.
• When doing pull requests, only add additions and changes to English at wekan/i18n/en.i18n.json . Other translations are done at https://www.transifex.com/wekan/wekan.
• If you have fix to some existing pull request, add your fix as comment. Do not post new pull request.
• For new features add new pull request, if there is none already.
• remove all console.log statements
• Fix all lint errors and warnings
• Add Snap settings to code so that feature is default disabled, and can be enabled with Snap commands
• Add Snap settings to wiki
• Add settings also to Dockerfile
• Make your pull request to edge branch.
• Use the feature branch workflow.
  • create a PR from your feature-branch to wekan/edge directly so that you can continue your work without interruption.
• Keep your local forks updated with this repo by setting your git upstream value as described here.
  • before submitting a PR make sure you rebase your local branch as described here
  • If you accidentally mess around on your edge branch, follow these steps here to clean it up.

Preventing Travis CI lint errors before submitting pull requests

• NOTE: Travis is currently broken and always shows warnings and errors like variables not defined or not used, so if your code works, ignore Travis.
• Eslint for linting. To prevent Travis CI lint errors, you can test for lint errors by installing npm install eslint and running it with npm run lint and trying automatic fixing with eslint --fix filename.js
• There is also probably not-currently-working as of 2018-05-05 jsbeautifer website with settings Indent with 2 spaces (topmost dropdown), [X] Space before conditional: "if(x)" / "if (x)", [X] Use JSLint-happy formatting tweaks.

Choosing issues to work on

• You are free to select what feature to work on.
  • Leave a comment on an issue saying that you're working on it, and give updates as needed.
  • Work and concentrate on one issue at a time and finish it, before moving to other issue.
• Keep list of your contributions on your personal website.
• Keep track of time it takes to implement each part of a feature, so you can estimate what time it would take to implement similar feature. After implementing feature, review your estimate was it correct, make improvements to your process and estimates, also keeping enough time allocated in estimate if something is harder to implement. Employers look for coders with proven track record.
• You can ask for comments from others, but usually those feature requests are clearly defined how they should work. You can place those Settings options there where it seems most logical for you.

Main point is to be friendly to those commenting of your code, and incorporate those suggestions that make most sense.

Build Pipeline

• Templates are written in JADE instead of plain HTML. Also see HTML to JADE converter.
• CSS is written in the Stylus precompiler - see Stylus to CSS converter, and
• Meteor templates are created as BlazeLayout templates.
• Instead of the allow/deny paradigm a lot of the collections defined in the project use mutations to define what kinds of operations are allowed.

For further details look for the 'feature summaries' in the Wiki (still in progress) otherwise go through the git history and see how old features were built. Might I suggest the Start and Due date feature wefork#26

Translations

If adding new features, please also support the internationalization features built in. Refer to the Translations wiki page.

Export From Trello

It's possible to import your existing boards from Trello. Instructions here

Directory Structure Details

Directory Structure

Chat