We will use this icon to mark check points.
A check point is a way for you to check how you are doing.

For most of the steps in this tutorial we will
provide the code as it should look after the task. It is tempting, we
know, but please, please, do not go for the “copy&paste” way.

We will use this icon to challenge you
with additional code-related tasks so you can go further at your own
pace. No inline answer will be provide for those challenges but we will
give you some guidelines and tips. By the way, within the instructions
we will use an italic font to refer to variables and pieces of code.

We will use this icon to ask you some questions related to the task your are working on.

Additional info and resources - this is not essential to complete the tutorial, but very interesting.

Tips that might help you on this task.

If you are following this tutorial as part of a workshop, do not hesitate to
raise your hand and share any questions or comments you may have.
If you are doing it by your own, you still can raise your hand in our
mailing list, just join our Google Group.

General conventions

visualization: biojs-events: A event system to send events to outside listener

state your license in your README

source folder structure: use either lib or src (the NodeJS convention is to
name it lib, but frankly it doesn’t matter)

Standards

We have defined some minimal standards that every BioJS package should comply with. If your package doesn’t fullfil those standards, it will be tagged via our io-ratings service and for now red warnings might appear. It could happen that we will take more drastic actions in the future.

1. Documentation

It is super easy to write usable documentation for your component, we don’t expect a masterpiece of modern literature, but especially the user should be able to know how to use your components ;-)
You could write your documentation with

README.md (recommended)

Github wiki

an API documentation generating framework (e.g. docco or jsdoc)

2. Working snippets (for vis components)

3. Lack of unit tests (especially for io components)

4. Responsiveness on github

We don’t expect you to fix an issue on the day someone opens (we are all busy people who have a day job), but if someone opens a pull request with a fix for the bug, you should respond to this within three days (72h) - after all merging something on github takes you less than 30 seconds (with opening the page).

Gold standard

The following standards are not required, but could enhance your public visibility.

Recommendation for new comers

We state possible recommendations and pointers for each item. They are aimed at new comers and you are absolutely free to choose your e.g. favorite testing framework.
For those recommendations to new comers: It is not so important how fancy they are. The key focus should be how easy they are to use and understand.