[CREATE] LGM11 panel proposal: attracting new devs

[Gregory Pittman]

On 02/23/2011 10:25 PM, Yuval Levy wrote:
> On February 21, 2011 03:32:18 pm Gregory Pittman wrote:
>>>      very interesting idea to write the manual first :)
>>
>> If we do this, it would be nice if some could show some prototype ideas
>> of what this might look like or how this might work. What would the
>> workflow be? How would documenters interact with coders?
>
> this discussion about writing the manual first has been going on for a few
> days now... and nobody has mentioned things such as mock ups or functional
> specifications?
>
> Well written specs are like a very detailed manual but you don't want to
> unleash them on the user because of too much detail that is relevant to
> analysis and coding but not to usage.
>
> It's a chicken and egg problem.  or a feedback loop.
>
> First there is a vision.  It is analyzed, dissected, recomposed and fleshed
> out; articulated into specifications including screens mock ups and functional
> specs.
>
> Then it is implemented into code and manual.  The processes are parallel and
> influence each other, with close/fast feedback loops.
>
> In an ideal world the initial analysis is so perfect; both coders and
> copywriters get it the first time so that when the software and the manual are
> delivered to the users, all they can say is wow!
>
> In reality nobody is perfect.  The analysts are likely to miss something in
> the func specs; the coders are likely to interpret / implement different than
> intended; the tester are likely to find new ideas that would significantly
> influence the vision that the analyst had not thought of in the first place;
> and so the stage is set for the next cycle leading to v+1.
>
> Simply taking a user manual as a specification document is not enough.  If it
> is, that manual is not user-friendly.
>
> There is no perfect workflow either, just put the people in the same room and
> get them to talk, talk, talk, until they understand each other, develop a
> common sense of purpose and leverage each other's skills.
>
> But it is not a user manual to drive the development.  It is use cases,
> analyzed and articulated into mock ups and func specs.

If I understand what Louis and a.l.e were trying to suggest, it was that 
to some extent documentation should try to stay ahead of development, 
before code is even written, so that a comprehensive, cohesive, and 
sensible workflow shows the program where to go. I think we can imagine 
that this is precisely how Steve Jobs has driven the development of 
various Apple products, by focusing on the user experience. One might 
also compare this to some authors of novels, who say that they begin a 
book by creating a set of characters and situations, and then let the 
characters determine where the story goes, and thus the book "writes 
itself."

The main question is, how do we translate this to an open source 
situation, with scattered volunteers working on a project? Those in the 
proprietary world might argue that we can't, and this is why open source 
is inferior. If we who are in various ways part of libre graphics don't 
agree, it's up to us to show some results that prove that. This is 
something that could be revolutionary, benefit every single project, and 
attract more interest from those willing to help.

There is a certain amount of creative play that can go on with a libre 
graphics program, but in many cases we begin with a mental concept of 
something we want to create, then try to most efficiently translate that 
to digitized form using whichever program(s) we choose. If we can manage 
to progress from needing to push a long series of buttons (keystrokes 
and mouse clicks) to something more like setting a row of dominoes 
toppling with a few pushes, we begin to make the process less effortful.

Greg