ubuntu-wanted-dev team mailing list archive

["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/>