RE: [Rosegarden-devel] The "wanna help" page

[Randall F. <rf...@si...>]

> Could I have a bit more input on this one please ? Rich, can you
elaborate 
> a bit on what you don't like about it ?

I'm not Rich, of course, but here goes:

Italicizing "cool ideas" and putting "Sensitive New Age Guys" in bold
makes it seem like you're being sarcastic, or like you really want to
write something more forceful but have to hold yourself back.

Contributors don't need Qt/KDE experience for everything: that's one
benefit of avoiding Qt in base. I did everything I've done so far (still
a bit more than I've sent in yet, eek) without much Qt experience. 

Here's a way to phrase some don'ts as do's:

* Think practical. All the time spent working on one feature is time
that can't be spent working on another. If your goal is to make software
that other people can use and enjoy, work on things that will give you
the best return (in usability) on your investment (of time). Improving
notation-editor performance is a higher priority than porting Rosegarden
to Qt/Embedded, for instance.

* Think specific. In an experiment, psychologists asked students to
choose a goal to accomplish over winter break, and had some of them
commit to specific ways of reaching the goal. The ones who made specific
plans -- "implementation intentions" -- were more than twice as likely
as the others to finish their project. To get your goals accomplished,
browse through the code and figure out early on what classes and what
functions you want to write or change, get an idea of what the
changes/additions will be, and decide when and how you want to start
coding.

(There's a graph attached, cribbed from
<http://www.columbia.edu/cu/psychology/courses/2630/lectures/lectures5-6
.ppt>.)

* Know what you're committing to. Coding is not always a glorious
enterprise: it's not like simply typing out the ideas or algorithms you
have in your head. Almost all programmers spend most of their time
debugging -- dealing with arcane things like operator precedence,
iterator invalidation, and missing pointer dereferences. So, before you
decide that you want to write a piece of Rosegarden, think about how
much effort it's going to take and about what else could be done with
that time.

(I'd've liked to have added a specific lines-of-debugged-code-per-hour
estimate to that, but I haven't found a good figure yet. Another graph
is attached, this one cribbed from <http://www.construx.com/sd2000.pdf>.
Using both graphs together might be aesthetically out of the question.
Hmm.)

> This kinda sucks because we now have two documents to maintain, but
given
> the document's size and scope, I don't think it's going to be much of
a
> problem.

You could just advise people in the docs/ directories to peek at the
generated documentation.