{"action":"opened","issue":{"url":"https://api.github.com/repos/lincolnloop/django-beancounter/issues/1","repository_url":"https://api.github.com/repos/lincolnloop/django-beancounter","labels_url":"https://api.github.com/repos/lincolnloop/django-beancounter/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/lincolnloop/django-beancounter/issues/1/comments","events_url":"https://api.github.com/repos/lincolnloop/django-beancounter/issues/1/events","html_url":"https://github.com/lincolnloop/django-beancounter/issues/1","id":196289404,"number":1,"title":"Add readme.md file ","user":{"login":"jsroyal","id":10773353,"avatar_url":"https://avatars.githubusercontent.com/u/10773353?v=3","gravatar_id":"","url":"https://api.github.com/users/jsroyal","html_url":"https://github.com/jsroyal","followers_url":"https://api.github.com/users/jsroyal/followers","following_url":"https://api.github.com/users/jsroyal/following{/other_user}","gists_url":"https://api.github.com/users/jsroyal/gists{/gist_id}","starred_url":"https://api.github.com/users/jsroyal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jsroyal/subscriptions","organizations_url":"https://api.github.com/users/jsroyal/orgs","repos_url":"https://api.github.com/users/jsroyal/repos","events_url":"https://api.github.com/users/jsroyal/events{/privacy}","received_events_url":"https://api.github.com/users/jsroyal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-12-18T18:03:57Z","updated_at":"2016-12-18T18:03:57Z","closed_at":null,"body":"Hey, I will give you format just write rest of the content.\r\n\r\n#  Project Title\r\n\r\nOne Paragraph of project description goes here\r\n\r\n## Getting Started\r\n\r\nThese instructions will get you a copy of the project up and run on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.\r\n\r\n### Prerequisites\r\n\r\nWhat things you need to install the software and how to install them\r\n\r\n```\r\nGive examples\r\n```\r\n\r\n### Installing\r\n\r\nA step by step series of examples that tell you have to get a development env running\r\n\r\nSay what the step will be\r\n\r\n```\r\nGive the example\r\n```\r\n\r\nAnd repeat\r\n\r\n```\r\nuntil finished\r\n```\r\n\r\nEnd with an example of getting some data out of the system or using it for a little demo\r\n\r\n## Running the tests\r\n\r\nExplain how to run the automated tests for this system\r\n\r\n### Break down into end to end tests\r\n\r\nExplain what these tests test and why\r\n\r\n```\r\nGive an example\r\n```\r\n\r\n### And coding style tests\r\n\r\nExplain what these tests test and why\r\n\r\n```\r\nGive an example\r\n```\r\n\r\n## Deployment\r\n\r\nAdd additional notes about how to deploy this on a live system\r\n\r\n## Built With\r\n\r\n* [Dropwizard](http://www.dropwizard.io/1.0.2/docs/) - The web framework used\r\n* [Maven](https://maven.apache.org/) - Dependency Management\r\n* [ROME](https://rometools.github.io/rome/) - Used to generate RSS Feeds\r\n\r\n## Contributing\r\n\r\nPlease read [CONTRIBUTING.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) for details on our code of conduct, and the process for submitting pull requests to us.\r\n\r\n## Versioning\r\n\r\nWe use [SemVer](http://semver.org/) for versioning. For the versions available, see the [tags on this repository](https://github.com/your/project/tags). \r\n\r\n## Authors\r\n\r\n* **Billie Thompson** - *Initial work* - [PurpleBooth](https://github.com/PurpleBooth)\r\n\r\nSee also the list of [contributors](https://github.com/your/project/contributors) who participated in this project.\r\n\r\n## License\r\n\r\nThis project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details\r\n\r\n## Acknowledgments\r\n\r\n* Hat tip to anyone who's code was used\r\n* Inspiration\r\n* etc\r\n \r\n\r\nAnd also you can add  contribute.md file which is written in markdown languga.\r\n\r\n# Contributing to the project\r\n\r\nPlease take a moment to review this document in order to make the contribution\r\nprocess easy and effective for everyone involved.\r\n\r\nFollowing these guidelines helps to communicate that you respect the time of\r\nthe developers managing and developing this open source project. In return,\r\nthey should reciprocate that respect in addressing your issue, assessing\r\nchanges, and helping you finalize your pull requests.\r\n\r\nAs for everything else in the project, the contributions to this project are governed by our team.\r\n\r\n## Using the issue tracker\r\n\r\nFirst things first: **Do NOT report security vulnerabilities in public issues!** Please disclose responsibly by letting [ this project team](mail to:team@thethis projectfirm.com?subject=Security) know upfront. We will assess the issue as soon as possible on a best-effort basis and will give you an estimate for when we have a fix and release available for an eventual public disclosure.\r\n\r\nThe issue tracker is the preferred channel for [bug reports](#bugs),\r\n[features requests](#features) and [submitting pull\r\nrequests](#pull-requests), but please respect the following restrictions:\r\n\r\n* Please **do not** use the issue tracker for personal support requests. Use\r\n  the [this project Chat](http://abc/chat/).\r\n\r\n* Please **do not** derail or troll issues. Keep the discussion on topic and\r\n  respect the opinions of others.\r\n\r\n\r\n## Bug reports\r\n\r\nA bug is a _demonstrable problem_ that is caused by the code in the repository.\r\nGood bug reports are extremely helpful - thank you!\r\n\r\nGuidelines for bug reports:\r\n\r\n1. **Use the GitHub issue search** &mdash; check if the issue has already been\r\n   reported.\r\n\r\n2. **Check if the issue has been fixed** &mdash; try to reproduce it using the\r\n   latest `master` or `next` branch in the repository.\r\n\r\n3. **Isolate the problem** &mdash; ideally, create a reduced test case.\r\n\r\nA good bug report shouldn't leave others needing to chase you up for more\r\ninformation. Please try to be as detailed as possible in your report. What is\r\nyour environment? What steps will reproduce the issue? What OS experiences the\r\nproblem? What would you expect to be the outcome? All these details will help\r\npeople to fix any potential bugs.\r\n\r\nExample:\r\n\r\n> Short and descriptive example bug report title\r\n>\r\n> A summary of the issue and the browser/OS environment in which it occurs. If\r\n> suitable, include the steps required to reproduce the bug.\r\n>\r\n> 1. This is the first step\r\n> 2. This is the second step\r\n> 3. Further steps, etc.\r\n>\r\n> `<url>` - a link to the reduced test case\r\n>\r\n> Any other information you want to share that is relevant to the issue being\r\n> reported. This might include the lines of code that you have identified as\r\n> causing the bug, and potential solutions (and your opinions on their\r\n> merits).\r\n\r\n\r\n## Feature requests\r\n\r\nFeature requests are welcome. But take a moment to find out whether your idea\r\nfits with the scope and aims of the project. It's up to *you* to make a strong\r\ncase to convince the project's developers of the merits of this feature. Please\r\nprovide as much detail and context as possible.\r\n\r\n\r\n## Pull requests\r\n\r\nGood pull requests - patches, improvements, new features - are a fantastic\r\nhelp. They should remain focused in scope and avoid containing unrelated\r\ncommits.\r\n\r\n**Please ask first** before embarking on any significant pull request (e.g.\r\nimplementing features, refactoring code), otherwise you risk spending a lot of\r\ntime working on something that the project's developers might not want to merge\r\ninto the project.\r\n\r\n### For new Contributors\r\n\r\nIf you never created a pull request before, welcome : tada: :smile: [Here is a great tutorial](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github)\r\non how to send one :)\r\n\r\n1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork,\r\n   and configure the remotes:\r\n\r\n   ```bash\r\n   # Clone your fork of the repo into the current directory\r\n   git clone https://github.com/<your-username>/<repo-name>\r\n   # Navigate to the newly cloned directory\r\n   cd <repo-name>\r\n   # Assign the original repo to a remote called \"upstream\"\r\n   git remote add upstream https://github.com/this projecthq/<repo-name>\r\n   ```\r\n\r\n2. If you cloned a while ago, get the latest changes from upstream:\r\n\r\n   ``` bash\r\n   git checkout master\r\n   git pull upstream master\r\n   ```\r\n\r\n3. Create a new topic branch (off the main project development branch) to\r\n   contain your feature, change, or fix:\r\n\r\n   ```bash\r\n   git checkout -b <topic-branch-name>\r\n   ```\r\n\r\n4. Make sure to update, or add to the tests when appropriate. Patches and\r\n   features will not be accepted without tests. Run `npm test` to check that all\r\n tests pass after you've made changes. Look for a `Testing` section in the\r\n project’s README for more information.\r\n\r\n5. If you added or changed a feature, make sure to document it accordingly in\r\n   the `README.md` file.\r\n\r\n6. Push your topic branch up to your fork:\r\n\r\n   ```bash\r\n   git push origin <topic-branch-name>\r\n   ```\r\n\r\n8. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)\r\n    with a clear title and description.\r\n\r\n### For Members of the this project Contributors Team\r\n\r\n1. Clone the repo and create a branch\r\n\r\n   ```bash\r\n   git clone https://github.com/this projecthq/<repo-name>\r\n   cd <repo-name>\r\n   git checkout -b <topic-branch-name>\r\n   ```\r\n\r\n2. Make sure to update, or add to the tests when appropriate. Patches and\r\n   features will not be accepted without tests. Run `npm test` to check that\r\n   all tests pass after you've made changes. Look for a `Testing` section in\r\n   the project’s README for more information.\r\n\r\n3. If you added or changed a feature, make sure to document it accordingly in\r\n   the `README.md` file.\r\n\r\n4. Push your topic branch up to our repo\r\n\r\n   ```bash\r\n   git push origin <topic-branch-name>\r\n   ```\r\n\r\n5. Open a Pull Request using your branch with a clear title and description.\r\n\r\nOptionally, you can help us with these things. But don’t worry if they are too\r\ncomplicated, we can help you out and teach you as we go :)\r\n\r\n1. Update your branch to the latest changes in the upstream master branch. You\r\n   can do that locally with\r\n\r\n   ```bash\r\n   git pull --rebase upstream master\r\n   ```\r\n\r\n   Afterwards force push your changes to your remote feature branch.\r\n\r\n2. Once a pull request is good to go, you can tidy up your commit messages using\r\n   Git's [interactive rebase](https://help.github.com/articles/interactive-rebase).\r\n   Please follow our commit message conventions shown below, as they are used by\r\n   [semantic-release](https://github.com/semantic-release/semantic-release) to\r\n   automatically determine the new version and release to npm. In a nutshell:\r\n\r\n   #### Commit Message Conventions\r\n\r\n   - Commit test files with `test: ...` or `test(scope): ...` prefix\r\n   - Commit bug fixes with `fix: ...` or `fix(scope): ...` prefix\r\n   - Commit breaking changes by adding `BREAKING CHANGE: ` in the commit body\r\n     (not the subject line)\r\n   - Commit changes to `package.json`, `.gitignore` and other meta files with\r\n     `chore(filenamewithoutext): ...`\r\n   - Commit changes to README files or comments with `docs: ...`\r\n   - Cody style changes with `style: standard`\r\n\r\n**IMPORTANT**: By submitting a patch, you agree to license your work under the\r\nsame license as that used by the project.\r\n\r\n## Triagers\r\n\r\nThere is a [defined process](TRIAGING.md) to manage issues, because this helps to speed up releases and minimizes user pain.\r\nTriaging is a great way to contribute to this project without having to write code.\r\nIf you are interested, please [leave a comment here](https://github.com/this projecthq/discussion/issues/50) asking to join the triaging team.\r\n\r\n## Maintainers\r\n\r\nIf you have commit access, please follow this process for merging patches and cutting new releases.\r\n\r\n### Reviewing changes\r\n\r\n1. Check that a change is within the scope and philosophy of the component.\r\n2. Check that a change has any necessary tests.\r\n3. Check that a change has any necessary documentation.\r\n4. If there is anything you don’t like, leave a comment below the respective\r\n   lines and submit a \"Request changes\" review. Repeat until everything has\r\n   been addressed.\r\n5. If you are not sure about something, mention `@this project/maintainers` or specific\r\n   people for help in a comment.\r\n6. If there is only a tiny change left before you can merge it and you think\r\n   it’s best to fix it yourself, you can directly commit to the author’s fork.\r\n   Leave a comment about it so the author and others will know.\r\n7. Once everything looks good, add an \"Approve\" review. Don’t forget to say\r\n   something nice 👏🐶💖✨\r\n8. If the commit messages follow [our conventions](@commit-message-conventions)\r\n\r\n   1. If there is a breaking change, make sure that `BREAKING CHANGE:` with\r\n      _exactly_ that spelling (incl. the \":\") is in body of the according\r\n      commit message. This is _very important_, better look twice :)\r\n   2. Make sure there are `fix: ...` or `feat: ...` commits depending on wether\r\n      a bug was fixed or a feature was added. **Gotcha:** look for spaces before\r\n      the prefixes of ` fix:` and ` feat:`, these get ignored by semantic-release.\r\n   3. Use the \"Rebase and merge\" button to merge the pull request.\r\n   4. Done! You are awesome! Thanks so much for your help 🤗\r\n\r\n9. If the commit messages _do not_ follow our conventions\r\n\r\n   1. Use the \"squash and merge\" button to clean up the commits and merge at\r\n      the same time: ✨🎩\r\n   2. Is there a breaking change? Describe it in the commit body. Start with\r\n      _exactly_ `BREAKING CHANGE:` followed by an empty line. For the commit\r\n      subject:\r\n   3. Was a new feature added? Use `feat: ...` prefix in the commit subject\r\n   4. Was a bug fixed? Use `fix: ...` in the commit subject\r\n\r\nSometimes there might be a good reason to merge changes locally. The process\r\nlooks like this:\r\n\r\n### Reviewing and merging changes locally\r\n\r\n```\r\ngit checkout master # or the main branch configured on github\r\ngit pull # get latest changes\r\ngit checkout feature-branch # replace name with your branch\r\ngit rebase master\r\ngit checkout master\r\ngit merge feature-branch # replace name with your branch\r\ngit push\r\n```\r\n\r\nWhen merging PRs from forked repositories, we recommend you install the\r\n[hub](https://github.com/github/hub) command line tools.\r\n\r\nThis allows you to do:\r\n\r\n```\r\nhub checkout link-to-pull-request\r\n```\r\n\r\nmeaning that you will automatically check out the branch for the pull request,\r\nwithout needing any other steps like setting git upstreams! :sparkles:\r\n\r\n# Issues\r\n Issue open : \r\n  It is not just like fun and You need also post a  valid post with the opening Issue.\r\n\r\nClosing Issue: \r\n  Actully this is also follow same above and It will need to more percise to resolve the problem and test yourself and then you can close. \r\n\r\n\r\n"}}
{"actor":{"display_login":"jsroyal"}}