We'd love to hear your feedback. SciNote was developed with the aim to be a collaborative open-source project, so please open new issues describing any bugs, feature requests or suggestions that you have.

DISCLAIMER: We firmly believe that our vision for the future of SciNote is the right one, therefore we reserve the right to accept OR reject any reported bugs and opened pull requests.

This GitHub repository is a place to discuss SciNote source code. If you have any questions regarding usage of SciNote, tutorials, etc., please contact our support by sending an email to info@scinote.net.

If we receive a lot of similar feedback, we will try to provide better instructions / readme-s / tutorials.

Issue reporting

For issue reporting, please visit our Jira page. It is an open source Jira that requires no sign-up (you can report issues as anonymous user). Detailed instructions about issue reporting are documented there.

Pull requests

We will consider high quality pull requests.

Things to Keep in Mind

  1. Whenever pull request requires additional work to be done on the client side (e.g. including a new Gem will requires calling of make build, adding database changes requires rake db:migrate task, ...), please specify that in the pull request description.

  2. Whenever implementing changes to the database layer, make sure to apply changes on the following locations:

  3. Code change/s inside ActiveRecord-s as needed,
  4. Code database migrations that need to be:
    • reversible - this can be done by using up and down methods.
  5. Fix model tests so they aren't potentially broken and (optionally) add new tests that will test the new functionality. Calling rake test:models must result in 0 errors & 0 failures.
  6. (related to model tests) Fix the fixtures so they are in lieu with the database changes.
  7. Fix the demo tutorial seeding method - first_time_data_generator.rb, so it will auto-generate potential new changes.
  8. When merging a database-related pull request, always make sure that schema.rb gets updated. This often means editing schema.rb by hand. Make sure all changes are persisted into this document, and that the schema version (ActiveRecord::Schema.define(version: <version>)) equals to the last migration in the application.

  9. All contributions need to follow our codestyle. We use Hound, so all pull requests will automatically be reviewed for codestyle by Hound and raised comments for all code validations. With some exceptions (Hound is pricky on some occasions), all Hound comments must be resolved before a pull request can be merged into the codebase.

  10. This blog post from Alex Gaynor nicely explains the whats, wheres, and all the other things about quality pull requests, as well as how to open them and review them.

Contributor License Agreement (CLA)

In order to accept your pull request, we need you to submit a CLA. You only need to do this once. If you are submitting a pull request for the first time, just let us know that you have completed the CLA and we can cross-check with your GitHub username.

Complete your CLA here

Code style

We keep SciNote's codebase consistent by using various code styling conventions. We want to keep this practice in the future, therefore all contributions should follow the below code styling rules provided by various linter configuration files:

We suggest using Atom, SublimeText 3 or Vim for SciNote development, but you can of course use anything to your liking.

You are encouraged to install the EditorConfig plugin for your text editor / IDE to make sure your editor is properly configured in terms of indentation style / level and file encoding.

Atom configuration

Atom (1.16.0) is an advanced text editor that supports all the mentioned linters. The code styling rules are included in the repository, and can be read by Atom's packages. Below is a list of packages/plugins that should get required linters working in Atom.

  • linter (2.1.4) - a base linter, which provides support for analysing code for potential code and styling errors and warnings.
  • linter-rubocop (2.1.1) - this Linter plugin provides an interface to RuboCop (0.48.1). It's a Ruby static code analyzer, based on the community Ruby style guide.
  • linter-eslint (8.1.7) - this Linter plugin for provides an interface to ESLint. It will be used with files that have the JavaScript syntax. You also need to install eslint-config-google - ESLint shareable config file for the Google coding style, on which our coding style is based.
  • linter-scss-lint (3.1.0) - this Linter plugin provides an interface to scss-lint (0.53.0). It will be used with files that have the SCSS syntax.
  • linter-erb (1.1.0) - this package will lint your ERB files in Atom by running them through erb -x and sending the output to ruby -c for checking.
  • atom-beautify (0.29.23) - styles the code of HTML, CSS, JavaScript, PHP, Python, Ruby, Java, C, C++, C#, Objective-C, CoffeeScript, TypeScript, Coldfusion, SQL, and more. We only use it only for ERB files, because linter-erb linter plugin only does code semantic validation, but not code styling validation. After installation, inside Atom go to this package's settings and check Beautify On Save for ERB.

NOTE In some cases (e.g. when using do with ERB methods like link_to, i.e. <%= link_to ... do %>, if the statement part doesn't have additional parameters (if any) in one line) linter-eslint linter plugin reports additional falsely errors. To avoid this, always double-save a file, and you'll only get "unexpected end-of-input, expecting ')'" error at the last (blank) line of the file, which can be ignored, since this is an issue of this package. Check if the file was formatted correctly, because things like < / div> won't get corrected by itself to </div>, and hence the whole file won't be formatted correctly, until you correct these kind of things manually. * Some line length may get longer than the maximum allowed when saving (and hence formatting on save), but this is OK, since this is again an issue of this package.