ubuntu-wanted-dev team mailing list archive

["Sense Hofstede" <sense@xxxxxxxx>]

2009/1/6 Sense Hofstede <sense@xxxxxxxx>:
> 2009/1/4 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
>>>
>>
>>
> Hello,
>
> After examining various possibilities I decided to stick with the
> current MVC-system and clean it up instead. I'm going to try to make
> the models more consistent and reduce the retrieval of data without
> models as much as possible.
>
> Regards,
> --
> Sense Hofstede
> <http://www.qense.nl/>
>
Oops, wrong thread.
I hope you don't mind.

Apologises for the inconvenience,
-- 
Sense Hofstede
<http://www.qense.nl/>