diff --git a/doc/contributing/issues.rst b/doc/contributing/issues.rst index ab014b595d5..6f8f7bfa6db 100644 --- a/doc/contributing/issues.rst +++ b/doc/contributing/issues.rst @@ -10,9 +10,11 @@ searching first to see if there's already an issue for your bug). If you can fix the bug yourself, please :doc:`send a pull request `! -Do not use an issue to ask how to do something - for that use StackOverflow with the 'ckan' tag. +Do not use an issue to ask how to do something - for that use StackOverflow +with the 'ckan' tag. -Do not use an issue to suggest an significant change to CKAN - instead create an issue at https://github.com/ckan/ideas-and-roadmap. +Do not use an issue to suggest an significant change to CKAN - instead create +an issue at https://github.com/ckan/ideas-and-roadmap. Writing a good issue @@ -22,21 +24,31 @@ Writing a good issue * Say what you were doing when it went wrong * If in doubt, provide detailed steps for someone else to recreate the problem. * A screenshot is often helpful -* If it is a 500 error / ServerError / exception then it's essential to supply the full stack trace provided in the CKAN log. +* If it is a 500 error / ServerError / exception then it's essential to supply + the full stack trace provided in the CKAN log. Issues process ============== -The CKAN Technical Team reviews new issues twice a week. They aim to assign someone on the Team to take responsibility for it. These are the sorts of actions to expect: +The CKAN Technical Team reviews new issues twice a week. They aim to assign +someone on the Team to take responsibility for it. These are the sorts of +actions to expect: -* If it is a serious bug and the person who raised it won't fix it then the Technical Team will aim to create a fix. +* If it is a serious bug and the person who raised it won't fix it then the + Technical Team will aim to create a fix. -* A feature that you plan to code shortly will be happily discussed. It's often good to get the team's support for a feature before writing lots of code. You can then quote the issue number in the commit messages and branch name. (Larger changes or suggestions by non-contributers are better discussed on https://github.com/ckan/ideas-and-roadmap instead) +* A feature that you plan to code shortly will be happily discussed. It's often + good to get the team's support for a feature before writing lots of code. You + can then quote the issue number in the commit messages and branch name. + (Larger changes or suggestions by non-contributers are better discussed on + https://github.com/ckan/ideas-and-roadmap instead) -* Features may be marked "Good for Contribution" which means the Team is happy to see this happen, but the Team are not offering to do it. +* Features may be marked "Good for Contribution" which means the Team is happy + to see this happen, but the Team are not offering to do it. Old issues ========== -If an issue has little activity for 12 months then it should be closed. If someone is still keen for it to happen then they can comment, re-open it and push it forward. - +If an issue has little activity for 12 months then it should be closed. If +someone is still keen for it to happen then they should comment, re-open it and +push it forward.