ubuntu-wanted-dev team mailing list archive

["Sense Hofstede" <sense@xxxxxxxx>]

Hello,

here the first and -- according to me -- most important subject that
should be discussed: tasks. How should they be shaped? What
information should they provide? How should they work?

Lets first have a look at the part of the Gobby document of the
meeting that deals with tasks:

    |On tasks|

    current behaviour:
    There is one type of task, to which skills(with three experience
degrees) and a length can be assigned. It contains a description,
poster id and title.

    desired behaviour:
    Two types of tasks: static(infinite number, like Bug Triager) and
dynamic(limited number, like Ubuntu Wanted designer), linked to skills
with the same link table as currently used. The current possible
length (e.g. A few hours per week for a limited     period of time.)
should be discussed.

During the meeting it was suggested to allow larger and smaller tasks
to be placed. Ubuntu Wanted should make it easy for people new to
Ubuntu to find a task and contribute their work, but also make it easy
for people already experienced with Ubuntu to find a new or second
task within the Ubuntu community. Both types of users, and all
possible variations, should be taken into consideration when designing
all of this.

There is already a rough definition of length/duration of the task
possible, but tasks with different durations can't be easily
distinguished at the front page.
What I suggest is this: posters don't give the duration of a task, but
tell the estimated size of the task and if it's continuous or just a
thing that needs to be done one time. I'm not sure how to show this
clearly in list views, but maybe Jorge has got an idea.

At the moment tasks are linked to a specific user and whether someone
interested in the task can apply or not is stored in the
'poster_contactable' field in the task's database entry. I think it
would be better to link a task to a team. The 'poster_contactable'
field should be deprecated; it's useless to post a task if you don't
want any replies. Instead of this option the author should be able to
choose between the formal application method and the informal one. To
save time we could only implement the informal way at first. All
contact information is stored in the team's database entry.

There is a separate skill link table. I think it would be OK to keep
it the way it's now.

This would mean a task would contain this information:
-id
-team_id
-title
-description
-application_method
-continuous
-estimated_duration
-status
-time_posted
-time_due
-static or dynamic
-number of people needed

I could have forgotten something, please tell if I did.

What do you think? Do you agree? Did I forget something or make a
horrible mistake? Please tell!

Regards,
-- 
Sense Hofstede
<http://www.qense.nl/>