Skip to content

Commit

Permalink
docs(react-instantsearch): remove mentions of ris (#2094)
Browse files Browse the repository at this point in the history 
Since we moved react-instantsearch to
https://github.com/algolia/react-instantsearch/ and
https://community.algolia.com/react-instantsearch/

We can now remove mentions of the old repo organisation along with old
release scripts and specifics
  • Loading branch information
@vvo
vvo authored Apr 4, 2017
1 parent 098e2da commit 0a76913
Show file tree
Hide file tree
Showing 8 changed files with 82 additions and 408 deletions.
44 changes: 36 additions & 8 deletions .github/ISSUE_TEMPLATE.md
View file
Original file line number Diff line number Diff line change
@@ -1,16 +1,44 @@
<!--
***************************
Thanks for participating in this project!
Please:
- make sure you are using the latest version of the library.
- do at least one GitHub search in current issues, maybe your question is already here
This form is to report issues or new features.
As for general questions like "How to hide results when the query is empty?",
please search or post a question to our discourse forum: https://discourse.algolia.com/.
In any case,
- make sure you are using the latest version of the library;
- do at least one search in current issues or questions, your question might already be answered;
- do include details, screenshots when it's a visual issue, console errors otherwise;
***************************
-->

**Do you want to request a *feature* or report a *bug*?**

**What is the current behavior?**
<!--
***************************
If the current behavior is a bug, please provide all the steps to reproduce and a minimal
[JSFiddle](https://jsfiddle.net/) example or a repository on GitHub that we can `npm install`
and `npm start`.
We have a simple online template for you to use as a base to explain your bug or issue:
https://jsfiddle.net/vvoyer/0wm3donb/4/
If you are requesting a new feature, we need to understand WHY would you
need this feature (your use case) or how you are limited with the current API.
***************************
-->

**Bug: What is the current behavior?**

**Bug: What is the expected behavior?**

**Bug: What browsers are impacted? Which versions?**

**Feature: What is your use case for such a feature?**

**Feature: What is your proposed API entry? The new option to add? What is the behavior?**

**If the current behavior is a bug, please provide all the steps to reproduce and a minimal
[JSFiddle](https://jsfiddle.net/) example or a repository on GitHub that we can `npm install`
and `npm start`.**
**What is the version you are using? Always use the latest one before opening a bug issue.**

**What is the expected behavior?**
<!-- Delete any HTML comment and non relevant questions -->
219 changes: 25 additions & 194 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,225 +1,56 @@
Hi (future) collaborator!
[![InstantSearch.js logo][logo]][website]

**tl;dr;**
- submit pull requests to develop branch
- use conventional changelog commit style messages
- squash your commits
- have fun
## Development

<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents**

- [Where to start?](#where-to-start)
- [New API proposal](#new-api-proposal)
- [How to write issues](#how-to-write-issues)
- [Development workflow](#development-workflow)
- [Serving the build](#serving-the-build)
- [Commit message guidelines](#commit-message-guidelines)
- [Revert](#revert)
- [Type](#type)
- [Scope](#scope)
- [Subject](#subject)
- [Body](#body)
- [Footer](#footer)
- [Squash your commits](#squash-your-commits)
- [When are issues closed?](#when-are-issues-closed)
- [Milestones](#milestones)
- [Releasing](#releasing)
- [Hotfixes](#hotfixes)
- [Releasing hotfixes](#releasing-hotfixes)
- [Documentation updates](#documentation-updates)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

# Where to start?

Have a fix or a new feature? [Search for corresponding issues](https://github.com/algolia/instantsearch.js/issues) first then create a new one.

Always check the status of the [develop branch](https://github.com/algolia/instantsearch.js/tree/develop) for the freshest code.

Always submit pull requests to the develop branch.

**Wanna help us?** All issues belonging to the [`next` milestone](https://github.com/algolia/instantsearch.js/milestones/next) can be worked on.

# New API proposal

If you have a new **API proposal** or change, create an issue describing it precisely:
- JavaScript API example
- Resulting DOM/effect

Here's an example: [New widget: hitsPerPageSelector (#331)](https://github.com/algolia/instantsearch.js/issues/331).
```sh
yarn
yarn dev:docs
```

# How to write issues
Go to <http://localhost:8080> for the example playground.

Start with some context, when and/or where you encountered the issue.
Go to <http://localhost:4000> for the documentation website.

Since instantsearch.js is a UI library, if your issue is UI related then adding a screenshot or (better) a GIF will make your issue a lot easier to understand.
## Code

# Development workflow
The code for InstantSearch.js is located in [src](src).

Requirements:
- [Node.js](https://nodejs.org/)
- [yarn](https://yarnpkg.com/en/docs/install)
- [Ruby](https://www.ruby-lang.org/en/)
- [Bundler](http://bundler.io/)
## Test

Run the local example:
We have unit tests written with [Jest](https://facebook.github.io/jest/):

Single run and linting:
```sh
npm run dev
# open http://localhost:8080
# make changes in your widgets, or in example/app.js
yarn test
```

Run local example and docs:

Watch mode:
```sh
npm run dev:docs
# open http://localhost:4000/
yarn test:watch # unit tests watch mode, no lint
```

Run tests and lint:
## Lint

```sh
npm test
```

# Serving the build

For some use cases like building a demo, you may want to serve the current build
on an http endpoint.

To do so:

```sh
npm run serve
```

Will build, watch for changes and serve instantsearch.css and instantsearch.js on http://localhost:8080.

# Commit message guidelines

We use [conventional changelog](https://github.com/ajoslin/conventional-changelog) to generate our changelog from our git commit messages.

**Some examples**:
- feat(rangeSlider): add new range option to the rangeSlider
- fix(refinementList): send the full algolia result to the noResults template

Here are the rules to write commit messages, they are the same than [angular/angular.js](https://github.com/angular/angular.js/blob/7c792f4cc99515ac27ed317e0e35e40940b3a400/CONTRIBUTING.md#commit-message-format).

Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:

```text
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
yarn lint
```

The **header** is mandatory and the **scope** of the header is optional.
Files are automatically formatted with prettier.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on GitHub as well as in various git tools.

## Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.

## Type
Must be one of the following:

* **feat**: A new feature
* **fix**: A bug fix
* **docs**: Documentation only changes
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
semi-colons, etc)
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **perf**: A code change that improves performance
* **test**: Adding missing tests
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
generation

## Scope
The scope could be anything specifying place of the commit change. For example `RefinementList`,
`refinementList`, `rangeSlider`, `CI`, `url`, `build` etc...

## Subject
The subject contains succinct description of the change:

* use the imperative, present tense: "change" not "changed" nor "changes"
* don't capitalize first letter
* no dot (.) at the end

## Body
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
The body should include the motivation for the change and contrast this with previous behavior.

## Footer
The footer should contain any information about **Breaking Changes** and is also the place to
reference GitHub issues that this commit **Closes**.

**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.

# Squash your commits

Once you are done with a fix or feature and the review was done, [squash](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) your commits to avoid things like "fix dangling comma in bro.js", "fix after review".

The goal is to have meaningful, feature based commits instead of a lot of small commits.

Example:
- `feat(widget): new feature blabla..`
- `refactor new feature blablabla...`
- `fix after review ...`
- **both commits should be squashed* in a single commit: `feat(widget) ..`

# When are issues closed?

Once the a fix is done, having the fix in the `develop` branch is not sufficient, it needs to be part of a release for us to close the issue.

So that you never ask yourself "Is this released?".

Instead of closing the issue, we will add a ` ✔ to be released` label.

# Milestones

- `next` => Ideas, questions, refactors, bugs that were discuseed, turned into clear actions by the maintainers. You can work on this.
- `x.x.x` => selected `next` actions to be done in a release. You can work on this.
- no milestone => Still need investigation / discussion

# Releasing

If you are a maintainer, you can release.

We use [semver](http://semver-ftw.org/).

This task will merge develop into master.
## Release

```sh
npm run release
```

# Hotfixes

All our work is done on the develop branch but it could be necessary to push a hotfix to the master
branch and do a patch release. To fix a very important bug.

For this, you should:
- add `HOTFIX` to the commit message **body**
- submit your pull request to the master branch

## Releasing hotfixes

You must be on the master branch.
### Beta release

```sh
HOTFIX=1 npm run release
npm run release -- -b # or --beta
```

## Documentation updates
Append `-beta.x` where x is a number to the version for beta, so 4.0.0-beta.2 for example.

If you have important documentation update to release without wanting to release
a new version of instantsearch.js, you can do a documentation hotfix.
## Update docs

Then once the hotfix is merged into master, the documentation will be updated automatically.
Documentation website is automatically updated by Travis when master is merged.
3 changes: 1 addition & 2 deletions LICENSE
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
The MIT License (MIT)

Copyright (c) 2015 Algolia
Copyright (c) 2015-present Algolia, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
Expand All @@ -19,4 +19,3 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Loading

0 comments on commit 0a76913

Please sign in to comment.