Contributing to sciNote

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

Before creating new issue make sure that you understand what should be expected result of some functionality. Then search for issues if your issue was already reported by someone else. Searching includes both issues title and description, so it should be easy to locate the potentially existing issues. Mind that some terms might have synonyms, so try to include those in your search as well. Make sure to include both open and closed issues in your search.

1. Issue description

When creating new issue, the issue description must describe following information:

Summary: Summarize your issue in one sentence (what goes wrong, what did you expect to happen).
Steps to reproduce: How can we reproduce the issue?
Relevant logs and/or screenshots: Please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise. Also, if your copied text contains # tags or other Markdown symbols, please use code blocks (```) or inline code blocks (`).

Any issue details that might not be obvious to other users should be added to issue description.

2. Issue labels

Every issue must also be marked with labels that:

explains type of issue (bug, feature, improvement);
explain issue priority (critical, high, medium, low).

Other fields like Assign to and Milestone can be skipped when reporting an issue.

Pull Requests

We will consider high quality pull requests.

Things to Keep in Mind

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.
Whenever implementing changes to the database layer, make sure to apply changes on the following locations:

Code change/s inside ActiveRecord-s as needed,
Code database migrations that need to be:
- reversible - this can be done by using up and down methods.
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.
(related to model tests) Fix the fixtures so they are in lieu with the database changes.
Fix the fake seeding rake task - db_fake_data.rake, so it will auto-generate potential new changes.
Fix the demo tutorial seeding method - first_time_data_generator.rb, so it will auto-generate potential new changes.
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.

3.7 KiB Raw Blame History