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)
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
