Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Phil, all

I'm really sorry, that I don't have the time to contribute to the
numbers of highly interesting and active threads here on the list.

But I don't even manage to read all the mails I receive on the most
important LibO lists. (I read all the mails here, even if I don't reply).

This mail (sent already three weeks ago [1]) needs some follow-up, and
it is important enough to deserve it's own thread.

Phil Jackson schrieb (in the thread "flying the ship ...":
Hi Bernhard

[...]

If possible, I'd like to see a degree of formalisation of how the
design team will work together with suggestions of stages for taking
an idea and transforming it into a form that we have agreement on for
submission to the pool of programmers.

I support the idea of a common approach for proposals and idea
development leading to a final stage agreed upon by the team and
proposed to the developers in a way they can work on them.

This is about building relationships between the design team members
 but also between the design team and programmers so they feel part
of the design team.

It's like selling ideas to management - well articulated ideas with
supporting evidence should make a difference in getting done what the
Design Team thinks by consensus is necessary to improve the product.

It's all about convincing one single developer that a proposal is
important, so he is interested in coding in this area.

And with some kind of formalism this might be easier - especially as we
are in a period where several important ideas are thrown together on the
mailing list, while the next steps (collective work, integration with
existing designs, UI / UX areas covered...) are not clear to the participants.

Here are some suggestions for stages;

1) Someone comes up with an idea

:-) should be the basic...

2) Idea is posted on
Design/WhiteBoards and emailed to team members

In my eyes the /WhiteBoard wiki page should become a table of links to all the items that have been proposed by people really interested in working on them.

We definitely need another area, where people can post their ideas for improvement who can't spend the time or have the expertise to work on these ideas.

Such ideas need a team member being attracted by the topic and interested in working on it. If there is nobody interested / able to work in it, it might be reactivated by someone scrolling the whiteboard site...

3) Idea is discussed
and debated with ample opportunity to test idea and gather arguments
for and against

... and improved by the input of other team members.

4) Goes to vote stage by design members after member
proposes that they do this - if passed goes to Stage 5)

I don't think that we need a formal voting on each and every idea. Small changes should need much less formalism than larger modifications.

Consensual discussion on the list will lead to a positive feeling of the team towards this idea. In such a case formal voting is not necessary.

5) A
Design/Whiteboards paper for the idea if constructed giving a
formalised breakdown of the idea - i.e. Overview, Introduction, Main
Body with evidence, conclusions (why idea is a good one) and
references/bibliography.

Designing a mockup to show my ideas to people dedicated to design and UX is not very hard in comparison to preparing a description of modifications leading to developers interest and understanding.

6) Submitted to programmers pool for their
feedback.

If possible, developers should be involved much earlier. Knowledge about the necessary amount of work on this topic is important for us too.

And they are not only asked for feedback - we should try to attract them to work on this topic. Otherwise the idea will need to become pushed by someone else - without any guarantee that it will be worked on sometimes in the future.
>
7) Followup

We need to make this reasonably professional without turning it into
 a Phd. It makes it transparent for all.

I imagine a wiki page containing these steps (perhaps as a follow-up an other introductory wiki page with all the information a new team member searches for) and all the necessary information about how to attract developers for such work.

Christoph already mentioned some kind of "design Easy-hacks", an idea we definitely need to follow.

I know that some of these things are already done, but using a system
will make it more likely that progress is seen to be made on some
very interesting and beneficial ideas.

What does everybody think?

I think we should try it - and find out about the areas we can improve and further LibO without all these formalisms...

Best regards

Bernhard

Cheers

Phil Jackson

[1]: http://go.mail-archive.com/80STRNtdj-ankO94T0iTN0CD_MU=


--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.