[GRASS-dev] GRASS at GForge first steps - second encounter

[Maciej Sieczka]

Hi,

In the past few weeks as time allowed I finished setting up the
trackers at GForge.

Before they are announced for users, I'm kindly asking
developers to have a look at what was done and let me know if there
is something that still needs a change or fix.

Under the GRASS GForge project [4] there are 9 trackers now:

 - code feature requests
 - code issues
 - code patches

 - doc feature requests
 - doc issues
 - doc patches

 - website feature requests
 - website issues
 - website patches

Issues tracker is for bugs, and "bad features", aka "defects".

Feature reqests for wishes.

Patches are for user submitted patches, if the user doesn't have CVS
write access but wants to share his fix. They will also be used for
patches which shouldn't go into CVS (yet), but we want to keep the
track of them for later.

When there is a an issue reported and nobody picks it up right away,
I'm going to be the first contact person - ie. gather more info until
it is a good material for a developer to work on; I'll also prune
duplicate reports, close obvious wrong ones, etc. I can also fix some
minor stuff like docs, shell scripts etc.

When patch is submitted to a patches tracker, and nobody steps up to
take care of the patch, there are first-contacts also, who will do a
similar job here:

Jachym Chepicky - code patches.
Scott Mitchell	- website patches.
Martin Landa	- doc patches.

As I don't have any programming skills, and my insight into GRASS
website is poor, code and website experts are inevitable to evalute the
submitted patches. For docs patches I'll try to help Martin as I can.
Many thanks Guys!

Trackers are available for public view, but in order to be able to
post (including creating a new report), you must setup your account at
GForge first [3]. This is to avoid http spam.

All trackers' new submitions will be automatically forwarded to
grass-dev list. All the following traffic will be stored in the tracker
and forwarded only to folks discussing the ticket. However, anybody can
"monitor" (see GForge manual [6]) any ticket, or a whole tracker, to be
forwaded all the related traffic.

If you want to be able to modify the contents of trackers, you should
request to join the GRASS project at GForge as "developer" [5].

GForge provides many functionalities. AFAIK, it was aggreed that we are
currently going to use only the trackers, as all the other
functionalities are implemented in the current GRASS infrastructure
(besides surveys; there might be some use for them - let's keep them in
mind :) ).

Although there are various project member "roles" possible to define,
IMHO we should only use 3: admin, developer and user:

1. "Admin" is in charge of managing requests to join the project and
configuring the GRASS project at GForge. Currently there are 2 admins:
I and Bernard Reiter. We could use another backup in case we are both
away. Anybody?

2. "Developer" can do most of the things that admin can. Only that he
doesn't have his duties and he can't remove the whole project.
But he still can add/modify/delete trackers as well as delete tickets
for good. It was neccessary to provide that much power to "developers"
so that they could move tickets between the trackers. "Developers" -
please use your power wisely and drop me a line before doing something
more intrusive :).

3. "User". He can open new tickets in the trackers, reply to other
tickets and "monitor", participate in surveys ("admin" and "developer"
can too, of course).

GForge manuals are here: [6].

[1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse
[2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse
[3]http://wald.intevation.org/account/register.php
[4]http://wald.intevation.org/projects/grass/
[5]http://wald.intevation.org/project/request.php?group_id=21
[6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1

Maciek