[clug] development topic for clug talk?
Brad Hards
bradh at frogmouth.net
Tue Aug 23 05:15:04 GMT 2005
On Mon, 22 Aug 2005 23:20 pm, Pascal Klein wrote:
> Just out of interest, would someone be able to give everyone (or me, if no
> one else is interested) some advice concerning how development happens in
> the GNU/Linux community.
I think that this is, in some ways, a very hard question to answer. Like most
reasonable size communities, the GNU/Linux community comprises of a number of
smaller groups. Those groups have varying levels of maturity, varying levels
of cooperation inside the group, varying levels of cooperation with other
groups (and the broader community), and widely varying expectations of their
members.
As an active user of GNU/Linux, you are part of the development process. How
much a part you are, and the influence that you exert depends on that
activity. For example, if you file a bug on a bugzilla somewhere, then you
are contributing. If it is a really high quality bug report (say, full steps
to reproduce the problem, a backtrace from a non-stripped build, and a patch
that fixes the problem) then you obviously have more influence than a bug
report that says "your app crashed! you all sux0r".
The other thing that is really important to understand is that there is no
management layer for most communities. It isn't a company - it is a bunch of
people working together. This is why you can't show up on a mailing list and
say "I'd like to help - where should I start?" - there is no-one in charge to
direct you. You need to find your place in the community - how you do that
depends on your skills, interests, and the time you can put in, and
(obviously) also the particular community that you are trying to become part
of.
General things that help:
* understand the environment in which the community exists. For example, the
kernel developers mostly work by mailing lists, while other communities do
more stuff by IRC or Instant Messaging type tools. Web forums and Usenet are
less popular, but still possible.
* first listen (read), then speak (write). You need to work with the
community, not across it. You need to understand the current situation within
that group. For example, if the project is in feature freeze, then providing
a new feature will likely get your work ignored - you'll only end up
frustrated.
* actions count. If you want to be taken seriously, you can just propose ideas
and never deliver.
* remember that it isn't that important - it is just a hobby, so when you stop
enjoying it, find something else to do (either a different project/group, or
something that doesn't involve software at all)
A specific example. Since you mentioned graphics and documentation, then
might be interested in KDE (perhaps you already use it?). KDE's artwork is
mostly coordinated on a mailing list (see
http://www.kde.org/mailinglists/#development), with some work on IRC
(#kde-artists) and a couple of websites (http://www.kde-look.org and
http://www.kde-artists.org). Similarly, documentation uses a mailing list
(kde-doc-english) and a little bit of IRC (#kde-docs).
If you need an idea of what to work on, then it usually works best if you work
on something that annoys you (eg there is no documentation for your favourite
application, so you write it). If nothing comes to mind, you can often get
some ideas from the bug tracker (eg http://bugs.kde.org). Some project keep
simpler tasks for new-comers - in KDE they're called "Junior Jobs" or JJ, and
the bug tracker has a special search just for those.
If all else fails, approaching people at CLUG (especially over pizza) might
help (although I won't be at the next one - I'll be en-route to
http://conference2005.kde.org :-).
HTH
Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20050823/34ccf929/attachment.bin
More information about the linux
mailing list