[GRASS-dev] GRASS at GForge first steps

[Maciej Sieczka]

Hi,

Thanks to Sascha Wilde the problem I had with rights assignement at
GForge is gone. It seems it was a user (my) error.

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

Under GRASS GForge project [4] I have set up two trackers for GRASS:
issues [1] and patches [2].

Issues tracker is for bugs, defects, wishes. I will take care of it in
terms of sorting out bugs which are doubtfull or lacking information. I
can also fix some minor stuff like docs, typos in the code, shell
scripts etc..

Patches tracker is for storing and managing the patches candidates
(both code and docs). Currently, they are often sent to dev list. If
they are not reacted upon quickly, or too intrusive to be applied right
away but valuable for future developmement, they happen to be
forgotten. The tracker might help us to manage them in a convenient
way. Jachym volunteered to maintain the code patches submitted. Thanks
Jachym! Is there somebody willing to take care of docs submitted?

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 the trackers' posts
are automatically forwarded to grass-dev list currently.

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, which I discuss later in this mail). Thus, although
there are various project member Roles possible to define, IMHO we
should only use 3: admin, user and developer:

1. Admin is in charge of accepting requests to join the project and
configuring the GRASS project at GForge. Currently I'm the only admin.
We need 2 (3?), in case I'm not available. Candidates?

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,
add/modify/delete trackers. He also can't delete a ticket permanently -
only the admin can. I think such restrictions are sane - getting
familiar with GForge options takes some time, and we don't want
accdental corruptions. Eg. I happened to remove a tracker by accident
when learning GForge. And I'm definitely not an expert yet.

3. User. He can open new tickets in the trackers and participate it
surveys (Admin and developer can too, of course).

Talking of surveys - Jachym suggested using this nice GForge feature.
Any GRASS project member at GForge can vote on the survey. Admin can
access the survey results, and create new ones. I was wondering if
GRASS folks find it usefull. Thus, I have created a survey for that :)
[7]. Opinions? The possible problem I see is that only admin can access
the survey results :(, and there is no way to change this (CCing
Bernhard if he has an idea). You can see an example results in the
picture attached (I accidently voted twice - as admin and as a testing
user).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: survey.png
Type: image/png
Size: 3781 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061104/be41f414/survey.png