gunghogeoduck/osem-fcy
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updating readme, install, payments, contributing files

Browse source
This commit is contained in:
Stella Rouzi 2017-03-13 14:29:52 +02:00
parent a826bb9d1e
commit e8699f4258
4 changed files with 109 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

90
CONTRIBUTING.md
View file

@ -1,4 +1,9 @@
# Request for contributions
# Contributing to OSEM
Our open source project is open to contributions. Open your [issue](https://github.com/openSUSE/osem/issues/new) and send a PR!
We welcome new developers, and we actively participate in mentoring programs, such as [GSoC](https://summerofcode.withgoogle.com/) and [RGSoC](https://railsgirlssummerofcode.org/).
## Request for contributions
We are always looking for contributions to OSEM. Read this guide on how to do that.
In particular, this community seeks the following types of contributions:
@ -7,7 +12,7 @@ In particular, this community seeks the following types of contributions:
* ideas: participate in an issues thread or start your own to have your voice heard.
* code editing: fix typos, clarify language, and generally improve the quality of the content of OSEM
### Runing OSEM for development
## Running OSEM in development
We are using [Vagrant](https://www.vagrantup.com/) to create our development environments.
1. Install [Vagrant](https://www.vagrantup.com/downloads.html) and [VirtualBox 5.0.10](https://www.virtualbox.org/wiki/Download_Old_Builds_5_0). Both tools support Linux, MacOS and Windows.
@ -57,14 +62,14 @@ You can access the app [localhost:3000](http://localhost:3000). Whatever you cha
vagrant exec bundle exec rake db:migrate
```
## How to contribute
## How to contribute code
* Prerequisite: familiarity with [GitHub Pull Requests](https://help.github.com/articles/using-pull-requests) and issues.
* Fork the repository and make a pull-request with your changes
* Make sure that the test suite passes before you request a pull and that you comply to our ruby styleguide.
* Please increase code coverage by your pull request (coveralls or simplecov locally will give you insight)
* One of the OSEM maintainers will review your pull-request
* If you are already a contributor and you get a positive review, you can merge your pull-request yourself
* If you are not a contributor already please request a merge via the pull-request comments
* If you are not already a contributor please request a merge via the pull-request comments
### Getting Started
@ -79,17 +84,33 @@ You can access the app [localhost:3000](http://localhost:3000). Whatever you cha
* If there is already such a discussion on the issue, you can go ahead and pick this up
* If not, please first leave a comment on how you want to implement it and wait for contributors' feedback
### Commits
* Commit title should be short and descriptive
* title (or summary line) is the first line of the commit message
* that says what the commit is doing
* in no more than 50 characters
* starting with a word like 'Fix' or 'Add' or 'Change'
* **without** a period (.) at the end
* followed by a blank line
* Commit messages are
* up to 72 characters
* with break lines
* Reference the issue(s) the commit closes
* https://help.github.com/articles/closing-issues-via-commit-messages
* If you haven't done so since the beginning, you should reference the issue when you squash your commits
### Pull Requests workflow
Please open a PR only when you have finished coding, and your changes are ready to be reviewed for merging.
Please open a pull request (PR) only when you have finished coding, and your changes are ready to be reviewed for merging.
* Title
* Include a comprehensive title about what this PR is doing
* Referencing the issue number on the PR title is not giving any information about what this PR is about
* The title should be short (50 characters maximum). You can add more information in the description
* The title should be short (50 characters maximum); you can add more information in the description
* Description
* Add a couple of lines about what is the problem you are trying to solve and how you have addressed it
* Add bullet points about the new things you are introducing, if applicable
* Reference the issue: https://help.github.com/articles/closing-issues-via-commit-messages
* Reference the issue(s) you are solving
* Add a screenshot of your change, if you are working on something that changes how the app looks like
* Automated checks
* We automatically run the [test suite](https://github.com/openSUSE/osem/blob/master/CONTRIBUTING.md#test-suite) and security checks on every PR
* Check back later to see if all checks were successful, if not, address them or leave a comment to ask for help
@ -99,7 +120,7 @@ Please open a PR only when you have finished coding, and your changes are ready
* Take care of your PR
* Make sure you check the status of your PR regularly
* Address your reviews, make the necessary changes, ask if something is not clear to you
* Rebase against newest changes, when needed, we cannot properly review PRs that are not rebased
* Rebase against newest changes, when needed; we cannot properly review PRs that are not rebased
Reviewing your PR might take some time, as we are all volunteers. Please be responsive and respectful.
@ -120,11 +141,15 @@ We are using [rspec](http://rspec.info/)+[capybara](http://jnicklas.github.io/ca
vagrant exec bundle exec rspec
```
## Code of Conduct
OSEM is part of the openSUSE project. We follow all the [openSUSE Guiding Principles!](http://en.opensuse.org/openSUSE:Guiding_principles) If you think someone doesn't do that, please let us know at maintainers@osem.io
### Review App of your PR
OSEM uses [Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps) on Heroku.
* The review app can be manually created by a maintainer, and when that happens you will see a relevant message in the PR
* Please help reviewers by adding the necessary data relevant to your PR,
eg. if your PR is doing something related to conference registrations, go to the review app and make sure there is a conference with registrations.
## Contact
GitHub issues are the primary way for communicating about specific proposed changes to this project. If you have other questions feel free to subscribe to the [opensuse-web@opensuse.org](http://lists.opensuse.org/opensuse-web/) mailinglist, all OSEM contributors are on that list! Additionally you can use #osem channel on freenode IRC.
### Email Notifications
**Note**: We use [letter_opener](https://github.com/ryanb/letter_opener) in development environment. You can check out your mails by visiting [localhost:3000/letter_opener](http://localhost:3000/letter_opener).
@ -144,3 +169,44 @@ config.ichain_force_test_username = "testuser"
# set email of 'testuser'
config.ichain_force_test_attributes = {:email => "testuser@example.com"}
```
## Labels for issues and PRs
...and what they mean!
1. **Bug**
* A bug in the application, something is wrong and needs to be fixed!
* Ideally the issue includes details on how to reproduce the bug
* Reproduce the bug in master branch, and send a PR that solves it
2. **Design**
* Related to the looks and/or usability of the application; needs attention from someone who understands front-end and UX
* If you are good with graphics and design, give it a shot!
3. **Documentation**
* Related to the documentation of our application, eg our INSTALL.md file or a wiki page with instructions on how to use the app, or part of it.
* If you are working on a documentation issue, make sure you are covering all cases.
4. **Epic**
* We may, or may not, solve this, thus it is epic. It's bigger than a feature request, because it fundamentally changes or affects the app, or a significant part of it.
* Do **not** work on this without prior discussion with the maintainers, it's called epic for a reason!
5. **Feature**
* This is a new feature for something new in the app!
* If an issue is labeled *Feature*, don't work on the issue, unless the maintainers have decided on how to proceed
* Ideally, leave a comment with your proposed solution in the issue and wait for feedback
6. **Grooming**
* This is working, but could look better, thus needs some attention and grooming.
7. **Hacktoberfest**
* This is for the issues included in the coding event of Hacktoberfest. You can ignore it, when the event is not on
8. **in progress**
9. **Junior**
* For new comers! RoR beginners or people unfamiliar with the application. Where you must start if you are interested in a mentoring program we participate in.
10. **need feedback**
* Maintainers' attention is needed to decide if this is something we want in the app, and/or how it should be implemented
11. **Operation**
12. **ready**
13. **Refactorization**
* Our code needs to be re-written; to avoid code duplication, or make the code more readable, or do things in a simpler way!
14. **Research**
* Ideas to explore; and think if there is anything we want to include in our app.
## Code of Conduct
OSEM is part of the openSUSE project. We follow all the [openSUSE Guiding Principles!](http://en.opensuse.org/openSUSE:Guiding_principles) If you think someone doesn't do that, please let us know at maintainers@osem.io
## Contact
GitHub issues are the primary way for communicating about specific proposed changes to this project. If you have other questions feel free to subscribe to the [opensuse-web@opensuse.org](http://lists.opensuse.org/opensuse-web/) mailinglist, all OSEM contributors are on that list! Additionally you can use #osem channel on freenode IRC.

5
INSTALL.md
View file

@ -25,7 +25,7 @@ If you have an heroku account you can also
</a>
## Configure
There are a couple of environment variables you can set to configure OSEM.
There are a couple of environment variables you can set to configure OSEM. Check out the *dotenv.example* file.
| Variable | Content | Purpose |
|---------- |--------- |--------- |
@ -70,10 +70,9 @@ $ bundle exec rake logo:reprocess
```
### openID
In order to use [openID](http://openid.net/) logins for your OSEM installation you need to register your application with the providers ([Google](https://code.google.com/apis/console#:access), [GitHub](https://github.com/settings/applications/new) or [Facebook](https://developers.facebook.com/)) and enter their API keys in `config/secrets.yml` file, changing the existing sample values.
In order to use [openID](http://openid.net/) logins for your OSEM installation you need to register your application with the providers ([Google](https://code.google.com/apis/console#:access), [GitHub](https://github.com/settings/applications/new) or [Facebook](https://developers.facebook.com/)) and enter their API keys, changing the existing sample values, in `config/secrets.yml` file, or in your environment variables found in *.env.production* file.
## Recurring Jobs
=======
Open a separate terminal and go into the directory where the rails app is present, and type the following to start the delayed_jobs worker for sending email notifications.
```
bundle exec rake jobs:work

50
PAYMENTS.md
View file

@ -1,33 +1,37 @@
# Integrate your Stripe account to accept your user's payments
Here you will find all the information that you need to setup your Stripe account into OSEM.
If you have any problems with installing don't hesitate to [contact us](https://github.com/openSUSE/osem#contact)
# Payments through Stripe
Here you will find all the information that you need to setup your Stripe account and integrate it into OSEM.
If you experience any problems, don't hesitate to [contact us](https://github.com/openSUSE/osem#contact)
## Configure Stripe into the application
To configure Stripe into your application all you need to do is add the private and publishable keys into the Rails environment.
You can register to Stripe [here](https://dashboard.stripe.com/register) and get your API keys for free.
**You need to set the API keys provided by Stripe into the application first to get the feature running.**
**To enable payments, you need to add the API keys, provided by Stripe, in OSEM.**
Add your Stripe API keys in `.env` file into these variables:
## Add Stripe credentials
To integrate Stripe into OSEM, all you need to do is add the *publishable* and *secret* keys into the Rails environment.
If you are using the application in development mode your config should look like this:
`STRIPE_PUBLISHABLE_KEY = 'pk_**test**_random123example456'`
`STRIPE_SECRET_KEY = 'sk_**test**_random123example456'`
The application in development mode can be used to test the whole test feature but is still not ready to be used by your users.
You need to use the live API keys to use the payment feature in production mode.
1. Register with Stripe [here](https://dashboard.stripe.com/register) and get your API keys for free
In production mode, it should look like:
`STRIPE_PUBLISHABLE_KEY = 'pk_**live**_random123example456'`
`STRIPE_SECRET_KEY = 'sk_**live**_random123example456'`
In this mode, you can start accepting payments from your users.
2. Add your Stripe API keys in the following variables of your `.env` file:
## Testing feature in development mode
You can test the payment feature in development mode with some test cards.
Check out the list of test cards [here](https://stripe.com/docs/testing#cards).
* For **development**
* `STRIPE_PUBLISHABLE_KEY = 'pk_**test**_random123example456'`
* `STRIPE_SECRET_KEY = 'sk_**test**_random123example456'`
In development mode, the Stripe integration is useful for feature testing purposes. However, if you wish to enable payments for users, you need to use the live API keys.
* For **production**
* `STRIPE_PUBLISHABLE_KEY = 'pk_**live**_random123example456'`
* `STRIPE_SECRET_KEY = 'sk_**live**_random123example456'`
3. You are ready to start accepting payments from users
## Feature tests in development mode
You can test the payment feature in development mode using test credit cards; check out the list [here](https://stripe.com/docs/testing#cards).
### PCI Self Assessment Questionnaire(SAQ)
> As long as you serve your payment pages over TLS, and use either Checkout or Stripe.js
> as the only way of handling card information, Stripe automatically creates a prefilled SAQ A questionnaire for you,
> and you won’t need to undergo a PCI audit. If card data is stored or transferred through your servers,
> As long as you serve your payment pages over TLS, and use either Checkout or Stripe.js
> as the only way of handling card information, Stripe automatically creates a prefilled SAQ A questionnaire for you,
> and you won’t need to undergo a PCI audit. If card data is stored or transferred through your servers,
> you are responsible for following PCI DSS guidelines for handling card data, and periodic audits by a PCI-certified auditor.
As we are using Stripe Checkout for accepting payments, Stripe will help you for filling SAQ for your application.

2
README.md
View file

@ -10,6 +10,8 @@
An event management tool tailored to Free and Open Source Software conferences.
OSEM actively participates in [GSoC](https://summerofcode.withgoogle.com/) and [RGSoC](https://railsgirlssummerofcode.org/).
## Installation
Please refer to [INSTALL](INSTALL.md) documentation file