OpenCV_Weekly_Duty

Alexander Alekhin edited this page Jun 16, 2016 · 2 revisions
Clone this wiki locally

OpenCV Weekly Duty

You’re on duty for a week. This is needed to keep things manageable. Right now we have two resources that should be maintained regularly. On all questions please contact Anna Kogan or Kirill Kornyakov.

Rules

  1. Always stay positive, say thanks and smile =)
  2. Ask people to participate: fix bugs, write documentation, add tests and submit their work as pull request.
  3. Get things Done. If you can resolve any issue by yourself, do it! Try to not bother other people. Try to review, cancel or approve proposed stuff, if you know for sure what should be done.
  4. Have courage to reject stuff, but always mention that the decision is not final.
  5. Follow How_to_contribute and Coding_Style_Guide documents.

Pull requests

Note: It’s highly recommended to use Watch GitHub feature for opencv and opencv_extra repo-s during the duty period.

Check every PR for its state and do corresponding actions:

  1. What should be checked when you see pull request first time:
    1. If you see that a good bugfix was proposed for the master branch, you can suggest to retarget it for the 2.4 branch.
    2. If the PR is trivial, you can assign it to yourself and review.
  2. All new PRs should be tested with BuildBot. If not, you shall press Run button on it.
    • If there are any issues with builders, send author the link to http://pullrequest.opencv.org.
    • All green PRs should be assigned to somebody for review. When you’re assigning a PR, please add a comment mentioning name, this will lead to email notification.
  3. All old PR should be checked and updated:
    • Assigned (but not replied) persons should be pinged.
    • If PR got some remarks, you ping author, and ask if we’ll fix issues. Status is new again.
    • If PR got some remarks, but author doesn’t respond for 2 (?) weeks, you should react. If the reviewer said that PR is worthwhile, it can be transferred to issue tracker. Otherwise, PR is closed with some non-offensive comment.

Patch “lifecycle”

Issue tracker

http://www.code.opencv.org/projects/opencv/issues

General

  • Every day you study the Activity on tracker and intrude each time this is needed.
  • Every time ask reporter if he is ready to resolve the issue by himself. If he observe some bug, he can try to debug it. If he knows the root cause, he can propose a patch in a form of pull request. So, ask to make pull request all the time! It really helps people to understand how open-source works!
    • If somebody reports an issue, you ask him to debug it himself.
    • If somebody attaches a patch, you ask him to make a pull request.
    • If somebody creates feature request, you ask him explain why it is needed and to prepare a pull request.

Obligatory

  1. Use all queries that a started from “Duty -…”
  2. Use Category = None query to select non-categorized issues and set them appropriate categories.
  3. Check if there are new issues with irrelevant priority or targeted to particular release, reset priority and target and put a comment to the issues(s).
  4. Cancel obviously inappropriate issues.
    1. Put a comment saying that the author can reopen it but with detailed description and possibly reproducing code.
    2. Redirect the author to OpenCV Q&A forum if you feel that the problem requires community help rather than OpenCV fixing.
  5. Reassign to authors the issues with incomplete description and ask for missing info in a comment:
    1. In particular target OS version/bitness, OpenCV version/package (or Git hash/tag for patches), reproducing code and input data; an ideal case if the submitter can provide a unit test that is compatible with OpenCV infra.
    2. For feature requests ask for purposes/profit of the requested feature(s).

Desired

  1. Assign unassigned issues to the person if you understand who should look at it, use the following index for reference
  2. If there are related existing issues (e.g. duplicates or more general tasks) set the Related Issues field.
  3. Fix bad formatted description text (or possibly ask the author to do this).

Issue “lifecycle”