ubuntu-wanted-dev team mailing list archive

["Nicolas Deschildre" <ndeschildre@xxxxxxxxx>]

Hey,

Sorry for the late answer, new year holidays!

On Tue, Dec 23, 2008 at 10:24 PM, Sense Hofstede <sense@xxxxxxxx> wrote:
> 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.

Indeed task estimated time and necessary skills are crucial
informations for users, and as such, they should be easily
identifiable and browseable. Possible ideas:
- An icon per skill (10 skills?).
 * The list of skills with these icons would be shown at the left, as
a skill list. Clicking on one of them list all tasks related to this
skill.
 * These icon combined with a meter sub-icon (like the network manager
icon) would represent a given level of skill. They would be used on
tasks description, quite visibly, e.g. 64x64 or more images.
- An icon per length. Same thing, quite visibly. And a list at the
left (simplified, e.g. "small time engagement", "medium time
engagement", ...)
- A big link "Looking for your first contribution?" pointing to a
search to easy and small tasks.

The idea is to have all the main informations by the blink of an eye.
With big icons, color codes, and such. And easy access for newbies to
what they're looking for.

(I'm not sure what you are meaning by "poster don't give the duration
of a task, but tell the estimated size of the task"... same thing?)

>
> 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.

We should allow both. I, as an individual, may want to post a task for
my small pet project.

> 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.

estimated_duration and continuous will give less information than with
the previous scheme. You'll get something like "30 minutes regularly".
But how regularly??

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

Well so far, on the functional side, it is basically working (but not
finished). What will make the difference is the user interface, the
way you present the informations. Information should be easily grasped
with visual stuff like color codes, icons, and easily browseable. That
will make all the difference between a successful product and a failed
one.

Cheers,
Nicolas

>
> Regards,
> --
> Sense Hofstede
> <http://www.qense.nl/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-wanted-dev
> Post to     : ubuntu-wanted-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-wanted-dev
> More help   : https://help.launchpad.net/ListHelp
>