Index: get-involved.xml =================================================================== --- get-involved.xml (revision 472453) +++ get-involved.xml (working copy) @@ -3,7 +3,7 @@ - Apache Harmony + How do I contribute, give feedback, fix bugs and so on? Harmony Documentation Team @@ -38,6 +38,10 @@ Bugs and other issues can be posted on the project JIRA +
  • Step-by-step instructions on reporting, resolving and closing issues are listed in + + Good Issue Resolution Guideline +
  • Additional documentation and discussion can be found on the project wiki Index: guidelines.xml =================================================================== --- guidelines.xml (revision 472453) +++ guidelines.xml (working copy) @@ -278,12 +278,16 @@
    -

    Ideas must be review-then-commit; patches can be commit-then-review. -With a commit-then-review process, we trust that the developer doing the -commit has a high degree of confidence in the change. Doubtful changes, -new features, and large-scale overhauls need to be discussed before -being committed to a repository. Any major change -must receive consensus approval on the mailing list before being committed. +

    + Ideas must be review-then-commit; patches can be commit-then-review. + With a commit-then-review process, we trust that the developer doing the + commit has a high degree of confidence in the change. Doubtful changes, + new features, and large-scale overhauls need to be discussed before + being committed to a repository. Any major change + must receive consensus approval on the mailing list before being committed. + For detailed instructions on reporting, resolving and closing issues, refer to + + Good Issue Resolution Guideline.

    Each developer is responsible for notifying the mailing list and Index: issue_resolution_guideline.xml =================================================================== --- issue_resolution_guideline.xml (revision 472453) +++ issue_resolution_guideline.xml (working copy) @@ -26,78 +26,78 @@ -

    +

    - This guideline covers a wide range of issues but not all of them. - If you cannot do one of the steps, then write a comment to the issue. + This guideline provides step-by-step instructions on reporting, resolving + and closing issues. If you cannot do one of the steps, then write a comment to the issue.

    + +

    - Use your common sense! -

    -
    - -
    -

      -
    1. Explicitly state the expected behavior and the
    2. - actual behavior of Harmony code. Use links to specs, rfcs, etc. -
    3. Try to create as small test case as possible. A patch - to test will be highly appreciated.
    4. -
    5. Provide max. information about steps necessary to recreate the bug. +
    6. State the expected behavior and the + actual behavior of Harmony code explicitly. Use links to + specifications, references, etc.
    7. +
    8. Create as small test case, as possible. A patch + to test is highly appreciated.
    9. +
    10. Provide maximum information about steps necessary to recreate the bug. If a patch for the test has not been supplied, provide as much - diagnostic information about the failure as possible (stack trace, - failure output, expected output etc).
    11. -
    12. Remember to use issue links if applicable.
    13. -
    14. Check the issue resolution when it is committed. Add a comment.
    15. + diagnostic information about the failure, as possible: stack trace, + failure output, expected output, etc. +
    16. Use issue links, if applicable.
    17. +
    18. Check the issue resolution, when it is committed. Add a comment.

    -
    + -
    -

    - Depending on the type of issue, do the following: -

      -
    1. - Issue is probably a non-bug difference, not a bug or invalid: + +

      To close the issue, define its type first.

      +

      + If the issue is a non-bug difference, not a bug or invalid, + you should do the following:

        -
      1. Discuss on the dev list.
      2. -
      3. Add a link to the discussion thread as a comment to issue.
      4. +
      5. Discuss the issue on the + developer mailing list.
      6. +
      7. Add a link to the discussion thread as a comment to the issue.
      -
    2. -
    3. - Issue is a bug: + +

      If the issue is a bug, you should do the following:

      :
        -
      1. Notify the community that you started investigation by adding - a comment to the issue and send a message to dev list. If you cannot - produce a patch, add another comment with the results of your investigation.
      2. +
      3. + Notify the community that you started investigation by adding + a comment to the issue and send a message to the + developer mailing list. + If you cannot create a patch, add another comment with your + investigation results.
      4. If reporter did not provide a patch to test: -
          -
        1. Try to create a patch to test.
        2. -
        3. If you cannot produce a patch, write a comment about it.
        4. -
        +
          +
        • Try to create a patch to test
        • +
        • If you cannot create a patch, write a comment about it
        • +
      5. -
      6. Create a patch to fix the issue. Any concerns? Discuss on the dev list. - Add a link to discussion as a comment.
      7. -
      8. All the pacthes (test and fix) should be relative to the directory where - the main build.xml is: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk. - Or to the module root directory.
      9. +
      10. + Create a patch to fix the issue. If you have any concerns, + discuss questions on the developer mailing list. + Add a link to the discussion as a comment.
      11. +
      12. All pacthes, test, and fix should be relative to the directory where + the main build.xml is:
        + https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk,
        + or to the module root directory.
      13. Test and fix patches should be in different files.
      14. -
      15. If the patch requires to add, remove or move some files in the repository, add the appropriate script.
      16. +
      17. If the patch requires adding, removing or moving some files in the repository, + add the appropriate script.
      18. Check that all unit tests pass.
      19. -
      20. If it is an application-oriented issue, check the application.
      21. -
      22. Remember to use issue links if applicable.
      23. +
      24. If the issue is application-oriented, check the application.
      25. +
      26. Use issue links, if applicable.
      -
    4. -
    -

    -
    + + -
    + +

    To close the issue, define its type first.

    - Depending on the issue type, do: -

      -
    1. Issue is a non-bug difference, not a bug or invalid: close the issue.
    2. -
    3. Issue is a bug: + If the issue is a non-bug difference, not a bug or invalid, you should close the issue.

      +

      If the issue is a bug, you should do the following:

      1. If a patch to test is available, apply it.
      2. Check that the test fails.
      3. @@ -108,11 +108,10 @@
      4. If there are problems on previous steps, post a comment to JIRA and let "resolution provider" to resolve.
      5. Make sure that the issue reporter is happy with the resolution.
      6. -
      7. Add revision info into JIRA issue.
      8. +
      9. Add revision info into the JIRA issue.
      -
    4. -
    -

    -
    + + +
    \ No newline at end of file