Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Suggesting a few improvements for the ticket workflow on t.e.o

Received: by 10.180.75.197 with SMTP id e5mr2649349wiw.1.1349721447632;
        Mon, 08 Oct 2012 11:37:27 -0700 (PDT)
X-BeenThere: trac-dev@googlegroups.com
Received: by 10.216.210.134 with SMTP id u6ls3113059weo.4.gmail; Mon, 08 Oct
 2012 11:37:25 -0700 (PDT)
Received: by 10.180.84.74 with SMTP id w10mr2629439wiy.4.1349721445886;
        Mon, 08 Oct 2012 11:37:25 -0700 (PDT)
Received: by 10.180.84.74 with SMTP id w10mr2629438wiy.4.1349721445876;
        Mon, 08 Oct 2012 11:37:25 -0700 (PDT)
Return-Path: <t...@dstoecker.de>
Received: from mail.stoecker.eu (mail.stoecker.eu. [2a01:4f8:d13:3800::1:5])
        by gmr-mx.google.com with ESMTP id fb20si1061623wid.3.2012.10.08.11.37.25;
        Mon, 08 Oct 2012 11:37:25 -0700 (PDT)
Received-SPF: neutral (google.com: 2a01:4f8:d13:3800::1:5 is neither permitted nor denied by best guess record for domain of t...@dstoecker.de) client-ip=2a01:4f8:d13:3800::1:5;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 2a01:4f8:d13:3800::1:5 is neither permitted nor denied by best guess record for domain of t...@dstoecker.de) smtp.mail=t...@dstoecker.de
Received: from mail.stoecker.eu (localhost [127.0.0.1])
	by filter.mynetwork.local (Postfix) with ESMTP id 93D2D1B2256
	for <trac-dev@googlegroups.com>; Mon,  8 Oct 2012 20:37:23 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.stoecker.eu
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=disabled version=3.3.2
Received: from localhost (localhost [127.0.0.1])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.stoecker.eu (Postfix) with ESMTPS id 80E171B21A7
	for <trac-dev@googlegroups.com>; Mon,  8 Oct 2012 20:37:23 +0200 (CEST)
Date: Mon, 8 Oct 2012 20:37:23 +0200 (CEST)
From: =?ISO-8859-15?Q?Dirk_St=F6cker?= <t...@dstoecker.de>
X-X-Sender: stoec...@talea.stoecker.eu
Reply-To: trac-dev@googlegroups.com
To: trac-dev@googlegroups.com
Subject: Re: Suggesting a few improvements for the ticket workflow on t.e.o
In-Reply-To: <CAMmgw9mUNe4j_HuwbM8XBrBtF3hTovEE_nKtjdOL4uu-7Rr...@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1210082012100.8...@talea.stoecker.eu>
References: <5071C499.6050...@free.fr> <k4shc6$jt...@ger.gmane.org> <alpine.LNX.2.00.1210072259110.10...@talea.stoecker.eu> <k4sv5m$ts...@ger.gmane.org> <CAMmgw9mUNe4j_HuwbM8XBrBtF3hTovEE_nKtjdOL4uu-7Rr...@mail.gmail.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 8 Oct 2012, Ethan Jucovy wrote:

> Does t.e.o have a keyword for these kinds of tickets?  As a 
> non-core-developer I'd like to help out and also get more familiar with 
> the core codebase, and little bugs that aren't worth a core dev's time 
> to fix sound like they might be good tickets to start on.  Or maybe 
> moving them into a special milestone would make it clear that no core 
> dev is likely to look at these, and also make them easy for someone like 
> me to find?

If you want to contribute (here or somewhere else), a short note about how 
to start (Target audience: Not only you :-)

a) Find something you want fixed/changed 'yourself'.

b) Read code and think a bit about how you would solve it.

c) Check whether there is already a report for it and maybe suggestions
    how to solve the issue.

c1) There is: comment at the relevant ticket with a short text how you
     think you will proceed to give maintainers a chance to guide you to the
     right path when necessary.

c2) There isn't: Either create a ticket or use mailinglist for additional
     guidance.

d) Start implementing.

d1) When necessary ask in mailinglist or ticket for help, but always tell
     what you did and why you did it and where your problems are.

e) Supply a patch

f) Fix the patch according to the requirements of maintainers.

g) Constantly nag until it is applied :-)

You can skip b) to c), but usually it makes f) easier.

One thing which is always important for me. When asking questions, 
describing strategies: Be short with the texts, but provide all 
information which may be necessary (the more the better, as long as the 
main question/suggestion stays short and understandable).

Why: From time to time for our software (don't know for Trac, but probably 
the same :-) we have tickets describing in great detail how a specific 
issue should be solved, but there is never any results from such posts. So 
today I simply ignore long tickets or solution descriptions.

Same for questions. If it takes too long to understand a question I ignore 
it. So keep the question short, but nevertheless provide the information 
which may be necessary. Note, that usually you will not know which really 
is necessary.

An anecdote: Lots of years ago it took me 2 days to create a bug report 
describing in detail a strange bug. The author of the software had a short 
look and found the bug in 10 minutes. He said that without that 
information it would have taken days to find the reason. It was a very 
small detail which helped him, which I would never have thought relevant 
at all :-)

If you still don't find anything: #10562 should be easy and you would make 
one of the users of one of my trac instances happy. :-)

P.S. I get constantly the question when to use mailinglist and when 
ticket: When there is the slightest chance that information may be 
relevant for others even if you stop implementing, then add it to the 
ticket (If necessary repeat it in mailinglist a little bit later). If 
questions are for your own learning, ask in mailinglist.

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)