Hi Nik,

before you'll never get a reply from my side ... :-)

Am Dienstag, den 25.10.2011, 14:52 +1100 schrieb Nik:
> 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;

Cool, thanks!

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

Fine.

> 2. Same as above, with every person making a decision adding their 
> initials alongside.

Fine as well.

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

I can help you, but I'm offline from tomorrow/Saturday until Wednesday.

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

Sure. From experience I'd say these are small things that can be tweaked
afterwards ... I've refined the Agenda and Minutes for the OOo Community
Council several times - so no worries.

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

Fine, although this might be optional ... if we start to have such a
fine grained tracking, a percentage value might be more helpful
(although project management experience tells us that 80% of the time
tasks reside between 95 ... 99%) ;-)

Thinking of that, I suggest to have a "last update" information. That
really helps to find orphans / clean up stuff that lies there for too
long. Having that in a separate columns makes this even sortable.

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

Mmh ... I think we should simply say that its in progress. Although I
love processes (and thus the separation of requirements collection vs.
solution creation), I think such fine grained status might be added to
the proposal itself (if required).

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

Okay, the "should provide focus (=guidance) for the regular contributor"
is okay to me.

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

Sounds fun ;-)

Just a question - what about new items that don't need to be active,
where do these get added. To the On-Hold list, status "in proposal"?
(Sorry if I missed that ...)

> 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:
[...]
> > 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.

Personally, I'd like to avoid doubled statuses (e.g. Whiteboard page and
tasks page). Then it gets a bit tricky ... I already work on two or
three Whiteboard tasks that might be less relevant to others. So to me
its active ... How would that look like on the Tasks list, if we only
have 4 active items?

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

> 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".
> =)

Hehe, hope that will work fine for everybody ...


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

Here, I object ... the deadlines should help us to coordinate the work
in advance. But as long as few people actively contribute its hard to
balance many of the tasks. And since "normal life" sometimes happens,
nothing should hurt.


> >>      * 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?

<insert_contributor_name_here>

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

Fine, but let's be a bit flexible and allow some change in priorities if
that's required due to external circumstances.


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

Thanks for that - really, really, appreciated :-)

I'm not on wireless, the laptop's battery is fine, but I'm running out
of energy. So, good night everyone!

Cheers,
Christoph



-- 
Unsubscribe instructions: E-mail to design+h...@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

Reply via email to