+
+There are some simple guidelines to writing ticket which will make
+prioritizing, tracking, and resolving problems more efficient.
+
+
+
Each ticket should relate to a single problem or feature.
+
Provide a descriptive subject.
+
Be as specific as possible about what is wrong.
+
Put the URL to the offending page in the ticket.
+
Describe the steps you took to produce the problem.
+
Provide sensible priorities and deadlines.
+
+
Justification
+
+
Each ticket should relate to a single problem or feature
+ In order to easily prioritize and track tasks we need to have a
+ state associated with each issue. The problem with "laundry list"
+ tickets is that some tasks get done, some get defered, and some
+ cancelled. It is never clear when the ticket is done and
+ individual fixes can't be approved so even if it nominally is done
+ things are likely to fall through the cracks.
+
+
Provide a descriptive subject
+ We look at summaries of tickets with subjects only and it is
+ much easier to find the relevant ticket with a descriptive subject.
+
+
Be as specific as possible about what is wrong
+
+ Problem descriptions that are too short or ambiguous are less
+ likely to get fixed than those that can be easily interpreted.
+
+
Put the URL to the offending page in the ticket
+
+ Having the URL in the problem description will streamline finding,
+fixing, and
+ verifying the ticket. You do not have to enter it as an HTML
+ href, simply including the full url ( including the http:// and
+ the trailing variables ) is sufficient.
+
+
Describe the steps you took to produce the problem
+
+ If we cannot reproduce your problem it will be much harder to find.
+ The problem can be related to the page visited proir to the page on
+ which the error occurs or may be related to the specific data you
+ input to a form.
+
+
Provide sensible priorities and deadlines
+
+ We make an effort to meet deadlines and fix things in priority
+ order but if all tickets are critical with a short deadline
+ we will not necessarily fix them in the order you would really
+ like.
+
+
+ Jeff
+Davis
+
+
+Last modified: Fri Mar 2 10:24:36 EST 2001
+
+
+
Index: openacs-4/packages/bug-tracker/www/patch-add.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/bug-tracker/www/patch-add.adp,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/bug-tracker/www/patch-add.adp 11 Sep 2002 14:03:25 -0000 1.1
+++ openacs-4/packages/bug-tracker/www/patch-add.adp 20 Sep 2002 15:08:57 -0000 1.2
@@ -2,4 +2,12 @@
@page_title@@context_bar@
+
+ The very short answer is diff -u or
+ better, cvs diff -u and in either case you should
+ then inspect the resulting patch file to insure that it is what
+ you expect and manually remove any changes which should not be
+ part of the submitted patch.
+
+
+
The best way: Make changes in a current cvs checkout
+
+
+ If you have made changes in a cvs checkout just type
+
+ cvs diff -Nu package-dir > patch-file
+
+ in the package /web/openacs-4/package directory to generate
+ the patch (see below if you have also added files).
+
+
+
The bad way
+
+ If you are working from code that is not a cvs checkout
+ (definitely less desirable, see below) then you should type
+ either:
+
+ which will do a recursive context diff of the old directory versus the
+ new directory (the -r flag) and generate patches which
+ will create new files if you have added files (the -N
+ flag).
+
+
+
Gory Details
+
+
General
+
+ We prefer patches be generated from the top-level directory of
+ the package so that it is clear from the patch where the file
+ belongs.
+
+
+ The -N flag will generate a chunk in the patch file
+ to create any new files you have added but please be careful
+ that the files that will created really should be part of the
+ patch. It is easy to have editor backup file and others show up
+ (although cvs diff generally does not have this problem).
+
+
+ Try to avoid reformatting large blocks of code unless absolutely
+ necessary. It is quite important that the changes be as small as
+ possible so the the patch maintainer can inspect the patch quickly
+ and apply it if needed.
+
+
+
cvs diff
+
+
+ If you have cvs commit and are going to commit your changes but
+ want to produce a diff for documentation purposes you should
+ cvs add any new files you have made first so that
+ cvs diff will produce a diff which will create the new files.
+
+
+ If you are working from an anonymous checkout you should do the
+ following to add diffs for new files to the patch file:
+
+ diff -u /dev/null package-dir/.../new-file >> patch-file
+
+
+
+
Non-cvs checkout
+
+ In an ideal world you would do a checkout from the head, make
+ your changes, test them, and submit a cvs diff as
+ above. If you are unwilling to do so, a diff based patch is
+ still useful to the project but is less likely to be applied
+ as quickly (if at all). Posting entire changed files is almost
+ useless since it is difficult and time consuming to find
+ what you have changed and such postings are entirely likely
+ to be rejected outright.
+
+
+ if you have new files to add to your patch, add them to the
+ patch file via:
+
+ diff -u /dev/null new-file >> patch-file
+
+