gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: GNUmed manual


From: Gour
Subject: [Gnumed-devel] Re: GNUmed manual
Date: Tue, 09 Sep 2008 17:59:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>>>>> "Karsten" == Karsten Hilbert <address@hidden> writes:

Karsten> I recount the experience we had with SGML-in-CVS back in the
Karsten> days.

Then we compare apples & oranges ;)

Karsten> I know that reStructuredText doesn't require more than an
Karsten> editor to write (so does SGML).

...and it works on every Python-platform.

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?

Karsten> BTW, it may be fairly convenient to convert TWiki markup to
Karsten> reST.

I'll do it!

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.

The thing which you speak about we may call tips & tricks or something
which can be periodically integrated into manual.

otoh, check python's dev docs - http://docs.python.org/dev/ - it's even
possible to have them pretty up-to-date.

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

>> If we want to have nicely-looking manual, wiki is not the way.
Karsten> No doubt about that.

Nice we agree on something. Voila!

Karsten> Yes, we release the manual several times per day. People ask
Karsten> about something on the list or in private mail. It gets
Karsten> described or fixed in the Wiki and everyone has better
Karsten> documentation immediately.

See above - tips & tricks!

Karsten> Well, who will do it if not you (or another volunteer) ?

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

Karsten> My humble feeling is that I surely wonder why you go around
Karsten> trying to change every single aspect of how this project has
Karsten> achieved release 0.3.1 but not actually *doing* any of the
Karsten> changes you propose ?

I didn't touch the main aspect of the project (yet) - code ;) - I'm just
proposing organizational changes to improve the project.


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

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.

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

Is it reasonable to publish bzr branches on LP, while you're still with
CVS?


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?

Well, I'll try to find out who is ready to use LP more with all the
proposed changes and then we are going to make a 'LP-fork' :-)


Sincerely,
Gour


-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

Attachment: pgpX7d7pubqvO.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]