Introduction

Code contributions are always welcomed.

Simone code is stored on GitHub, and GitHub's pull request's are used for merging code changes from people who does not have write access to repository. You cannot send patches in ZIP files, using JSFiddle or via Skype. GitHub's the only way, with translations being the only exception. If you're unfamiliar with Git, there are some great resources to get you started, including Try Git, an online learning tool, basic course on GitHub, and the Pro Git book with in-depth analysis of all Git features.

General guidelines

There are few things to remember:

  • Simone comes with tests. New features without any tests written to it, or with poorly written tests, will not be merged until test coverage is satisfactory.
  • QUnit is used for testing, and it's trivial to learn. If you never wrote tests, it would take you an hour or two to wrap you head around it. If you have experience with unit testing frameworks, you'll learn Qunit momentarily.
  • Bug fixes should also be tested. You can benefit from test-driven development here. (Basically: 1. Write failing test for the bug. 2. Fix the bug. 3. Test is now passing. 4. Profit.).
  • Patches fixing Simone for unsupported browsers (IE8, Safari 5, Opera 12) will not me merged.

Coding standards

jQuery UI's coding standards apply to Simone, with a few modifications:

  • Ignore rules that are marked as those that should be moved to widget factory docs.
  • Ignore parts about z-index stacking.
  • You can use data() on element and it's subordinates, just call removeData() on destroy or when element is no longer used.

Please follow JavaScript Style Guide, with the following exceptions:

  • Ignore the part about JSLint. If you run JSLint on your code, it's fine, but if you don't, that's fine too. Please don't fix errors reported by JSLint on parts of code that you didn't contributed.
  • Ignore the part about multi-line statements when it comes to strings.

Please also remember to:

  • Trail whitespaces before committing changes. Your favourite editor probably has some plugin for it. Search online for how to turn it on, if you're unfamiliar with this concept.
  • Use spaces, not tabs, for intending multiline var statements (not everyone use 4 spaces for tab), for example:
function foo() {
	var a, // first a tab, because function should be intended,
	    b, // but then four spaces
	    c; // (select code with mouse to see it clearly)
}

Versioning

First version of Simone was 0.1.0.

Major versions, like 0.2.0, 0.3.0, and so on, are versions introducing new features, extending existing features, containing API redesigns, dropping off deprecated features, dropping support for versions of jQuery and jQuery UI, and so on.

Maintenance releases, like 0.1.2, 0.2.1, and so on, will only contain bugfixes for major versions. They can however contain documentation extensions, new demos, new languages, and new tests for existing features.

Commits

When committing, remember about few things:

  • Commit messages should be informative. Inform to what features, new or existing, is you commit related to, and in what manner.
  • Include issue ID in form of #123, if your commit related to a issue from the issue tracker.
  • Make separate commits for logically separate changes. Don't join multiple issue into one commit, and don't generate multiple commit for a single issue (squash them instead). Pull requests that don't follow those two rules will not be rejected, though. It's just a good self-discipline.

Pull request

  • Make pull request from a separate branches. git checkout -b descriptive-branch-name is all that's needed, and it leaves your master branch in peace for easy future pulls from original repository.
  • Make pull request with at least commit message. The more information you provide, the better. Please do not left conversation the moment you've made pull request. People might have questions or comments for you (GitHub will inform about them you if you didn't changed defaults settings).

Discussions

Talking is good. Discussing major changes before you're gonna do them is always a good idea. That way you gonna avoid contributing code that will not be finally merged, and you can get feedback on your ideas. Please also start a new issue when you would like to tell about you're experience with this project documentation, demos, or code. If you don't want to share that publicly, drop an email to the author.