Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.
The "IssueWorkflow" page has been changed by JoshSoref: https://wiki.apache.org/cordova/IssueWorkflow?action=diff&rev1=6&rev2=7 Comment: Wikify page === Make File Changes === Let's update the accelerometer documentation for the "watchPosition" function. - As it happens, the docs repository is organized with a top level `docs` directory. Inside the `docs` directory is a folder for each language, the canonical language is English (`en`). Inside each language are folders, one for each released version of Cordova, and an `edge` folder for the next version of Cordova. API documentation is inside that directory in a directory named `cordova` (there's also a Guide for how to use Cordova in the `guide` directory). Inside the API directory, documentation is organized by plugin, the accelerometer is part of the geolocation plugin and is thus in the `geolocation` directory. At the next directory, there's a class document `geolocation.md` (similarly named in the other directories according to their respective directory names) and documents for each method `geolocation.watchPosition.md` (with the second part of the file varying according to the respective method). + The docs repository is organized with: + * a top level `docs` directory. + * a folder for each language. + * The canonical language is English (`en`). + * one folder for each released version of Cordova. + * `edge` folder for the next version of Cordova. + * `guide` directory - a Guide for how to use Cordova. + * `cordova` directory - API documentation. + * documentation is organized by plugin, the accelerometer is part of the geolocation plugin and is thus in the `geolocation` directory. + * Class document `geolocation.md` (similarly named in the other directories according to their respective directory names) + * Method documents `geolocation.watchPosition.md` (with the second part of the file varying according to the respective method). - Thus, we're going to want to work on `docs/en/edge/cordova/geolocation/geolocation.md`. Specifically, we're going to announce that this API is now available on the HailOS platform. Typically you'd perform some more meaningful change to a file, and you'd use an editor for that. (For this change, you can expect feedback to complain that the insertion should be sorted alphabetically, but it's just a demo, unless we want to include that in a later section.) + Thus, we're going to want to work on `docs/en/edge/cordova/geolocation/geolocation.md`. Specifically, we're going to announce that this API is now available on the '''HailOS''' platform. Typically you'd perform some more meaningful change to a file, and you'd use an editor for that. (For this change, you can expect feedback to complain that the insertion should be sorted alphabetically, but it's just a demo, unless we want to include that in a later section.) {{{ $ perl -pi -e 's/(- Android)/\1\n- HailOS/' docs/en/edge/cordova/geolocation/geolocation.watchPosition.md @@ -73, +83 @@ # no changes added to commit (use "git add" and/or "git commit -a") }}} - git status shows that you have modified one file. + `git status` shows that you have modified one file. === Commit the File Changes === git add will stage the file changes. You can then commit the staged file(s) with git commit. This is the standard process to make changes to a git repository: stage, then commit. @@ -109, +119 @@ paragraph form, with each line wrapped at 72 chars and blank lines between paragraphs. }}} - Note that the first line does two things: (1) it is less than 50 characters. Subsequent lines after the first may exceed 50 characters. (2) it references a Jira issue by its id (CB-1234). Commonly, there should be a Jira issue open for defects and new features, and it is good practice for commits to point to the Jira issue they are addressing. And vice versa, you should add a comment to the Jira issue referencing the commit id(s) that contain your work. By adding the Jira number to the front of the commit message, you can take care of both in one step: there will be an [[http://www.apache.org/dev/svngit2jira.html|automatic comment]] added to the Jira item with the commit id, and of course the Jira item id will be in the git commit message. + Note that the first line does two things: + 1. it is less than 50 characters. Subsequent lines after the first may exceed 50 characters. + 1. it references a Jira issue by its id (CB-1234). + + re: Jira issue references: + * There should be a Jira issue open for defects and new features + * Commits should point to the Jira issue they are addressing. + * Comment in the Jira issue referencing the commit id(s) that contain your work. + * Including the Jira number at the beginning of the commit message, you can take care of both in one step: + * there will be an [[http://www.apache.org/dev/svngit2jira.html|automatic comment]] added to the Jira item with the commit id + * of course the Jira item id will be in the git commit message. Additionally, if your commit is to the {{{cordova-js}}} repository, then you are encouraged to add a prefix to the first line of your commit message that identifies which platform the change is for, as multiple platforms use this repository. This helps make it clear which platform authors should take interest in this commit. Here are 2 examples: @@ -127, +147 @@ * all automated tests in mobile-spec, * manual tests in mobile-spec that might be affected by the change, * any platform-specific unit tests - * cordova-android/test, + * `cordova-android/test` - * cordova-ios/CordovaLibTests, + * `cordova-ios/CordovaLibTests` - * cordova-js jake test, + * `cordova-js`: `jake test` - * cordova-plugman npm test, + * `cordova-plugman`: `npm test` Please add a comment in Jira about what testing you did with your change, so a committer can understand what testing was done before they merge your change. Please where reasonably feasible add automated tests to validate your change and catch any future regressions.
