Re: [libreoffice-design] Flying the ship... [please everybody, post a short reply]

Hi All

I'd like to put together a small sub-team to work on formalising all the 
ideas on getting a transparent structure together. I've been fairly busy 
over the last week with my own work but had a chance to see all the 
useful contributions and previous work done on creating structures and 
processes.

I appreciate that some members like Bernhard are already doing much more 
than they can be expected to and would be happy to act as coordinator of 
this sub-team as it carries out its work.

I'm looking for about a total of 3-5 members for this sub-team. I would 
expect that this small project will take 2-3 weeks. We can use the 
knowledge and experience of others to get feedback on our proposals as 
we suggest them so we don't overlook useful ideas and suggestions.

I suggest that we create a tag specifically for this project i.e. [DTF] 
standing for Design Team Formalisation or maybe someone can come up with 
a more apt one.

So for those that want to get involved in this, let me know and we'll 
aim to get started in the next week. We can put together a simple 
outline which will expand where necessary on the obvious initial steps of ;

1) Set the general brief for the project in clear, unambiguous language
2) Summarise previous work and suggestions
3) Discuss and design the structure
4) Get feedback
5) Changes as required (repeat 4 and 5 as necessary)
6) Plan for implementation
7) Implement

We can then try this out on real things to do and monitor how well the 
structure works and what tweaks are required.

Cheers

Phil Jackson



On 6/5/2011 9:06 AM, Bernhard Dippold wrote:
> Hi Vamsi, Phil, all
>
> sorry for this short reply (and top-posting), but I'm still more than 
> busy with the discussion on how our larger community will evolve after 
> the OpenOffice.org donation to Apache and the license shift from LGPL 
> to Apache V 2.0 where every (free or corporate) entity (including 
> Microsoft) can take the code without being obliged to contribute 
> anything back.
>
> I marked Phil's mail for replying once I read it first - it is very 
> reasonable and leads to more transparency in our team to have such a 
> kind of formal guideline.
>
> What I'd like to see is a "how we work" area in the wiki we can point 
> new members to - being quite similar to a formal paper, but more 
> friendly to new contributors...
>
> Best regards
>
> Bernhard
>
> Vamsi Kodali schrieb:
> > +1 to Bernhard.
> > Now that that's out of the way, I request you to please consider Phil's
> > proposal. I think that almost all (if not all) the steps he mentioned
> > are being followed now too, just in a unorganized way. I believe that
> > bringing a organized and managed scheme for new ideas and conveying it
> > to the people involved in a clear manner will tidy up and improve the
> > productivity of the entire process.
> >
> > Thanks,
> > Vamsi.
> >
> > On 05/25/2011 04:59 PM, Phil Jackson wrote:
> > > Hi Bernhard
> > >
> > > We need some structure and therefore we need someone unofficially or
> > > officially to lead it. I'm more than happy for you to take on that 
> > > role.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > Here are some suggestions for stages;
> > >
> > > 1) Someone comes up with an idea
> > > 2) Idea is posted on Design/WhiteBoards and emailed to team members
> > > 3) Idea is discussed and debated with ample opportunity to test idea
> > > and gather arguments for and against
> > > 4) Goes to vote stage by design members after member proposes that
> > > they do this - if passed goes to Stage 5)
> > > 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.
> > > 6) Submitted to programmers pool for their feedback.
> > > 7) Followup
> > >
> > > We need to make this reasonably professional without turning it into a
> > > Phd. It makes it transparent for all.
> > >
> > > 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?
> > >
> > > Cheers
> > >
> > > Phil Jackson


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