On Mon, Feb 21, 2011 at 2:27 PM, Mushon Zer-Aviv wrote:
> Well,
> There are methodologies that are already being used. Basically, the whole
> field of information architecture and the whole process of
> wireframing/prototyping/testing is all about documenting strategy. Coding
> (should) happens on
Mushon,
That is a really fine and provocative suggestion on your part—to write about
software that does not exist but should. It seeks the excluded middle
between the Floss Manuals which are too perfunctory on the one hand and too
presumptuous on the other *(An Open Web,* which I also worked on, b
Well,
There are methodologies that are already being used. Basically, the whole field
of information architecture and the whole process of
wireframing/prototyping/testing is all about documenting strategy. Coding
(should) happens only after that.
We need open tools for interface prototyping. If
I totally agree Mushon. Totally. Manuals are dead. Atrophied. Even
worse when they get printed.
Yes, totally, make future manuals, then fill in the blanks to them.
That is totally the approach I took in participating in the open web book:
http://openweb.flossmanuals.net/
There is a book sprint
On Feb 21, 2011, at 4:17, Gregory Pittman wrote:
> All fodder for discussion at LGM. Certainly we need to get out of the dark
> ages of documentation as an afterthought.
>
> Greg
>
This is actually a huge issue I recently discussed with Adam Hyde of Floss
Manuals. FM was initially establish
On 02/20/2011 01:20 PM, a.l.e wrote:
salut louis
One hopes that it can progress in tandem with the code, by
necessity a bit behind cutting-edge features
Actually, shouldn't that be the way around? Documenting is thinking.
We can look at this from two ends. Case #1 The program exists and it
is
salut louis
> > One hopes that it can progress in tandem with the code, by
> > necessity a bit behind cutting-edge features
>
>
> Actually, shouldn't that be the way around? Documenting is thinking.
> We can look at this from two ends. Case #1 The program exists and it
> is (partially) or (not w
2011/2/20 Gregory Pittman
> One hopes that it can progress in tandem with the code, by necessity a bit
> behind cutting-edge features
Actually, shouldn't that be the way around? Documenting is thinking. We can
look at this from two ends. Case #1 The program exists and it is (partially)
or (not
On 02/20/2011 07:57 AM, Boudewijn Rempt wrote:
documenters is a problem -- and that is purely my fault. I've tried to
write the manual on my own, but I don't have time.
This is certainly a worthy aspect of any discussions. At Scribus, we
have had something of an evolutionary development of docum
On February 20, 2011 02:23:50 am Alexandre Prokoudine wrote:
> It's quite the same with Inkscape, except that some of the students
> stick and continue working past their projects.
oh, we got those too. I don't know if Inkscape has more; and I don't know if
our experience is representative. St
On February 20, 2011 02:37:50 am Alexandre Prokoudine wrote:
> Could we get straight to
> actually communicating to potential contributors, please?
Let's start identifying them first?
Being a contributor is a mindset. We are all users, but some of us, for
whatever reason, decide to give back.
On Saturday 19 February 2011, Yuval Levy wrote:
> On February 19, 2011 06:49:40 am Boudewijn Rempt wrote:
> > Krita is one of the few libre graphics projects that
> > doesn't really have a dearth of developers. I'm sometimes worried about
> > the churn, and about the way my day job interferes these
12 matches
Mail list logo
