diff --git a/docs/basics/planning.md b/docs/basics/planning.md new file mode 100644 index 0000000000000000000000000000000000000000..41433e95ba386cd855ffc75eb5d671a690f9cd99 --- /dev/null +++ b/docs/basics/planning.md @@ -0,0 +1,90 @@ +# Planning your project + +## Community input + +Before you start on any code to extend CiviCRM, it is really important +to discuss your ideas with the community. Here are a few of the reasons +why this is a good idea: + +- It may have been done already +- You'll get suggestions and advice on suitable ways to approach the + problem +- Other people will know what you are doing, and be able to contact + you if they want to collaborate + +A typical pre-development workflow will start with a discussion on +[Mattermost](https://chat.civicrm.org/) (in the Developer channel) about what +you want to do. Here you'll receive feedback from other members of the +community and core team about your ideas. You might be lucky and find +out that there is a already a way to do what you want using the user +interface (and that no coding is necessary). Or it might be that someone +has done something similar already and all that is required is a few +tweaks to their code. + + +## Requirements and specifications + +If and when you have confirmed that some coding is required, it is good +practice, even for relatively small projects, to write + +- a requirements document which describes in detail what you want the + finished code to do +- a specification that outlines how you are going to meet these + requirements with CiviCRM + +The requirements are typically written to be understandable to end +users, and the specification can be thought of as a translation of those +requirements into the language of CiviCRM. Both requirements and +specification should go on the +[wiki](http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+Wiki). + +Once you've written the requirements and specification document, you +should go about soliciting feedback. Get feedback on the requirements +from your end users and feedback on the requirements and the +specification from anyone that is willing to comment. To encourage more +discussion, you can write a post on CiviCRM's +[blog](https://civicrm.org/blog/), tweet it out with +the [#civicrm](https://twitter.com/hashtag/civicrm) hashtag, tell similar +CiviCRM users and organisations and so on. +The more feedback you can get the better. + +If you get stuck writing your requirements and specification, or would +like to get more background, have a look at some +[existing requirements and specifications](https://wiki.civicrm.org/confluence/display/CRM/Requirements+and+specifications) +from CiviCRM developers. + +## Recommendations + +**Use Git and [GitHub](https://github.com/)** for revision control. +The official CiviCRM [repositories](https://github.com/civicrm) +are housed on GitHub. If you use GitHub you will find +it easy to access the latest source-code, to submit pull requests +for any patches you create and to collaborate with many other +CiviCRM developers who also use GitHub. + +**Create a native [extension](/extensions/basics)**. +If you have new functionality to add to CiviCRM, it probably belongs in an +extension. "Native" extensions will install into all CiviCRM sites +regardless of the underlying CMS used (Drupal or Wordpress), making it easy to +share your extension with the CiviCRM community. + +**Use the [API](/api/general)** to access and manage CiviCRM data in any patch, +native extension, CMS module, or external program that you +develop. The API will function as expected with every new release +and backwards compatibility of the API is maintained for several +versions of CiviCRM. + +**Follow the +[Coding Standards](https://wiki.civicrm.org/confluence/display/CRMDOC/Coding+Standards)** +for uniform structure that will make everyone's development work easier. + + +## Make it happen + +If you need or would like extra resources for your code improvement, you +might consider a [Make It Happen](https://civicrm.org/make-it-happen) +(aka MIH) campaign, which is a crowd-sourcing initiative for CiviCRM. +The MIH work is carried out by the +core team or trusted consultants, and has helped build many amazing new +features into CiviCRM in recent years. + diff --git a/mkdocs.yml b/mkdocs.yml index 20dda015bb390f58edf0afb56239717def8bffef..dc3bf51408ceef98d4fb62cc58f7dede6e636c55 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -13,6 +13,7 @@ pages: - Developer Community: basics/community.md - Prerequisite skills: basics/skills.md - Requirements: requirements.md + - Planning your project: basics/planning.md - Build: build.md - Customize: customize.md - Extend: extend.md diff --git a/redirects/wiki-crmdoc.txt b/redirects/wiki-crmdoc.txt index 7733b3027ab094f21ac00b5e22a1b6a1cbe88fb0..0432d8f3ea807ed5e0bc33212eb68f7ddfd4d61d 100644 --- a/redirects/wiki-crmdoc.txt +++ b/redirects/wiki-crmdoc.txt @@ -1,4 +1,6 @@ Documentation+Infrastructure+Canary develop The+developer+community basics/community Create+an+Extension extensions/basics +Before+you+start basics/planning +Recommendations basics/planning The+codebase core/architecture