[libreoffice-design] Re: Work Items Management

Hi Christoph, Klaus-jürgen, All,

Thank you both for your input, you thought of a number of things I 
didn't. I'm going to try condense your questions and provide short(ish) 
responses so that this thread does not become large and difficult-to-follow;

*Klaus-jürgen mentioned;*
1. Who will determine the priorities?  I think mostly our lead(s).
2. Who will determine where to put an item (active - on-hold)?
3. As I understand your proposal, the items will be more different than 
the work-item-list [1]. Will you/we make a list to collect the different 
items before 1st of november?
4. The status "On hold" won't be necessary because then it will be in 
the "ON-HOLD" list
5. The status "Being finalised" won't be necessary because then it will 
be in the "completed archive" list or you must have a coloumn "Status" 
in this list, too.
6. What is the difference between "In proposal" an "In progress"? Maybe 
this should be described.
7. What will happen, if someone tells that he wants to work on a 
"ON-HOLD" item, but the list of active items is 'full' and the others 
don't think it is extremly neceassary to work on it? We won't prevent 
him to work on it. Example: Aleksander made some (great) design 
proposals "out of time".
8. Maybe this example can be a extra list: "GENERAL items" with no 
priority.
9. I'm not sure if we shouldn't colour the "On-HOLD" list, too

*My suggestions regarding these very pertinent questions;*
1. When added, the member adding should assign a priority of discussed 
on this mailing list and then put there initials in brackets alongside 
the number, eg: 3(NS). The Team leads will review this priority when 
they get a chance and their reviewed ranking shoulod just be accepted to 
keep things going. SC members who frequent this list (Charles, Italo) 
would also be able to review priorities. Our Mailing list should not 
become endless discussions and contradictions of our priorities, that is 
why we appointed Team Leads.
2. Same as above, with every person making a decision adding their 
initials alongside.
3. That is a good point I hadn't considered. Can someone help me 
establish the current status and contacts for each of the existing 
tasks. (just add it to the bottom of the current wiki task list page to 
avoid complicating this thread).
4. Good point. But I kept the "on-hold" status to make it easier to 
cut-and-paste a record easily between the ACTIVE tasks and the ON-HOLD 
tasks. Ths way less editing is required.
5. I think we need a "Being finalised" to indicate work is complete on 
the task, but we need to wrap things up (like providing a graphic in 
another format, or waiting on word from the printers etc). It will also 
give us a final "push" to finish the job.
6. In proposal means that requirements for the task are still being 
established, while a task In-progress already has requirements defined 
and is currently being worked on or available to be worked on.
7. Being realistic I think we all know we can't "force" everyone to play 
the same game. We shouldn't. When additonal "out of time" contributions 
are made, we should accept them and move on to what is required. The 
task list on the Work-items page should be to provide focus for the 
regular contributors to this team. It should give direction and make the 
"endorsed" work items clear to anyone wanting to help in our everyday 
operations. Right now, that is not so clear.
8. If we define such a generic list, I'm afraid everything will be 
stored there, we will relax our focus on delivering results. We should 
instead be more rigid: A task is either a) being worked on b)suspended 
due to external influences or c)complete. No lee-way.
9. I'm not opposed to that, but I'd prefer if the only colours on the 
page were alongside things that can be worked on.

And Christoph I'm going to snip alot of your Email to so I can keep my 
responses just as "snappy";


On 11.10.25 08:10, Christoph Noack wrote:
> The most important question to me is, whether the availability of the
> existing list did attract anybody to work on such items. Most of them
> are still open ... unfortunately.
I don't think it did, because in my eyes at least, it was more of a 
heavy wiki-page and not a task-list.
I want to change it to a short and snappy task list. Soemthing I can 
check on quickly even when I'm off-list to get an impression of what is 
happening, how we are faring.
> What I became aware in discussions at the FOSDEM, the Hackfest and the
> LibO conference is, that we miss a simple way to explain new
> contributors what they can do.
That is a different issue but relevant. We have no "starter pack", which 
we've identified before.
I want to work on that soon also, but this takes priority for me. No 
point making it easy to join the team when it isn't clear what you need 
to work on right?
> So, where do we currently work on tasks and have some task management?
>        * http://wiki.documentfoundation.org/Design#Work_Items
>        * http://wiki.documentfoundation.org/Design/Whiteboards (already
>          having a simple Recent Topics / Past Topics section)
>        * Bugzilla (usually smaller tasks)
>        * libreoffice-ux-advise (usually smaller tasks, if bigger, then
>          moved to a Whiteboard)

Almost everything should remain functioning like it does now, but 
detailed info should move to Whiteboards and the Work items page should 
serve as a short linked index to all our tasks. Something to look over 
quickly.
> Back to your proposal - would it help to change the objective of the
> tasks list? My take ... a rough proposal:
>        * Larger task will (should) automatically require a Whiteboard
>          page. The whiteboards overview page might benefit from your
>          proposed structure.
>        * Smaller tasks that new contributors (with varying skills) might
>          take, should go to a separate section like EasyTasks /
>          StarterTasks. A similar structure to the task list (which still
>          keeps the fun) is required here.
>        * All other tasks that are less urgent, nobody takes care of
>          quickly  should go to an "Open Tasks" list. Just to not forget
>          them ...
>        * Bugzilla and libreoffice-ux-advise should stay as they are.
>
> What do you think?
Larger tasks: listed on Work-items page with a link to its Whiteboard page.
Smaller tasks: Leave them on this mailing list, we should try to keep 
the work-items focused.
I do not want the Work-items page tables to be about "types/categories" 
of tasks, I want them to be about the "stage/lifecycle" of that task. 
Just active, suspended or done. That's all that matters if we are trying 
to keep it simple.

> Color coding means that somebody has to decide on the priority ...
Yep. You! Or Bernhard.
Generally a member can do this and you can review the prioritisation.
We shouldnt' get tripped up over this. We elected you both because we 
trust you and this is an example.
When you get the chance review the priorities, otherwise they will be 
worked out on-list with little discussion hopefully.
Less talk, more "DO".
=)

> >      * We need to have deadlines,
> Yep, if we agree that these should guide but hurt (in terms of
> deadlines).

I think they should hurt us if we don't meet them. This is about 
establishing Design as a team that delivers and can be counted on. Even 
if nobody else tracks this, we should. My proposal: every day that a 
project/task runs over schedule should be counted and displayed on our 
Design wiki "home" page. A bad (high) number will hopefully urge us to 
get it done to salvage our worth as a part of this community. A good 
(low) number can be a source of pride amongst ourselves that we deliver 
when people need us. It will be our performance indicator.

> >      * We need to have a client and a representative who speaks on their
> >        behalf.
> Yep. At least someone will send the request ...
>
> However, I think another helpful thing would be to provide information
> that tells what we need if someone requests a certain item (I've
> collected some ideas for visual design elements, but did not send them
> to the list / wiki yet ... maybe the next task).
agreed, the requirements should be specific and in the examples, I've 
demonstrated that every requirement should be a deliverable and 
measurable item. Something identifiable as a satisfactory outcome or not.
> >      * We need to be organised and update this ourselves
> True, but this will need help by everybody ... which I currently miss a
> lot. We have many people on this list, but only veeery few who are
> active (whatever small or larger task it may be).
Any volunteers to help with this? we have 150 suibscribers.
Someone might be interested in helping whip us into shape?


> > and most drastically;
> >
> >      * *We should LIMIT the number of active tasks to just 3-4.*
> Mmh, I really like that for my own stuff ... when looking back at the
> last weeks, my work might have appeared a bit unfocused. (Which it
> wasn't, of course *g*). However, can we really limit the number of tasks
> for if people are free to chose where to spend effort?
>
> If we can agree that "active tasks" means something like "Tasks in
> Focus", then I'm fine.

We need to start taking this seriously. We can only get so much done in 
the time we have.
That means to need to start prioritising HARSHLY!
We need to be realistic and we need to push back if we can't do it.
Otherwise we will let everything be added as a task and nothing finished.
It works in COUNTLESS methodologies.
> > What do you think?
> Well, maybe more input that you've expected ... you should surely read
> it as "being happy that you kicked that off" :-)
>
> Cheers,
> Christoph

Sorry if any of that sounded harsh. I'm on wireless, battery is dying 
and this needed to be sent.
Let's get active!

-Nik

--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted