Re: [Gnumed-devel] Re: GNUmed manual

[Karsten Hilbert]

On Tue, Sep 09, 2008 at 05:59:33PM +0200, Gour wrote:

> Karsten> The toolchain I am referring to is the generation of
> Karsten> presentable content. Someone who contributes to a manual wants
> Karsten> to see that "in print". A wiki does that nicely.
> 
> Have you checked deps for docutils & sphinx?

No. But I know that a Wiki has only two dependancies: a
working browser and a working internet connection.

> Karsten> That "later" is the problem. I want to be able to edit a few
> Karsten> things - et voila, the manual is improved for everyone.
> 
> When I'm speaking about 'manual' I'm thinking about doc which documents
> major features in stable releases, not something which is changed every
> few days.

I do understand that you are not talking about the entire
wiki but only the manual as such.

> The thing which you speak about we may call tips & tricks
Not only. I am often updating the manual during night shift.

> or something which can be periodically integrated into manual.
That much is true.

> Karsten> The other thing: I don't *have* my editor at 3am. All I have is
> Karsten> a Windows based machine set up for medical practice and
> Karsten> internet access.
> 
> Even Notepad-like editor?
> 
> Which OS you run that you don't have any text editor available ? :-D

Of course I have an editor available. Let's assume the
manual is reST in VCS. What do you propose the workflow to
be like ?  Here's what needs to be done:

- getting the latest version from VCS
- editing
- compiling to check whether it is well-formed and looks OK
- checking in
- generating at least HTML
- upload to the "manual url"

How do I do that if all I have is a Windows machine with
Notepad ?  And no, I can certainly not install anything on
that machine.

Compare with a Wiki:

- surf to page
- edit
- preview
- save

Nevertheless, a better manual is surely something desirable !

> We can help doing it, but some of those things require that you modify
> your workflow a bit as well.

You call the above "a bit" ?

> And, so far, I cannot do much without being clear what is the consensus
> in regards to those proposals.

Regarding collecting bug reports at Launchpad there is no
need for consensus. Just do it and if it works better than
what we have - great.

> Karsten> Now, you've been starting with changing the way bugs are
> Karsten> triaged. I think that's a great start. Why not just stick to
> Karsten> that and get it done ?
> 
> I like to have the whole picture and things are interdependent - what is
> the use of bug tracker if you don't want to use it by e.g. closing
> tickets.
Why of course will someone close fixed bugs. But being able
to close bugs in a tracker isn't exactly the point of using
a tracker, right ?

> Does it make sense to write the manual in reST and you are going to
> continue to update wiki?

Sure, because it enables me to contribute 7 days and nights
of the week rather than 2 or 3.

> Is it reasonable to publish bzr branches on LP, while you're still with
> CVS?
Sure, if it proves that it is easily and completely
syncable, for example. Some people may prefer to check out
bzr rather than CVS. It'd be the same code, after all.

> Karsten> All said and done we don't need proposols just for the sake of
> Karsten> proposing. We need people *acting* on proposals.
> 
> So, you think that I propose just for fun?
No. But you didn't act on any. (Except now for starting to
act on the bug tracking issue - which is great.)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346