Hey, John. No problem. I've been mostly out of commission too, and will be for another two weeks. But we can certainly discuss during that time, at least a bit.

John & Melonie Curwood wrote:

Hi Joshua,

Sorry I haven't been in contact for the last couple of weeks, we've had a lot of trouble getting the phone connected (and hence the internet) in our new house so I have been out of touch. I am now back up and running.

Have you had any more thoughts on developing a plan or to-do list for the manual.

A couple of things I was thinking of were:

1. Divide the the work into a - what just needs to be proofed b - what chapters need finishing c - what new chapters/sections need to be created as a result of new

developments in 0.47

Sounds good. One thing we want to do is make sure that any new stuff is put into the right place - there's been a lot of reorganizing to make sense of not-always-rational processes (at least in a human logic :) And we want to avoid multiplication of chapters with each release, simply because if we add new stuff every release, it will become an unmanageable monster.

Part of the reason we have the content that we have and avoided other content is simply manpower. It's already beyond management for the manpower we have, so we'll do best to keep it manageable and fill it with worthy content. So every little detail doesn't need to be documented, necessarily, at this point, but the important stuff does.

A good place to start from is the release notes. Alexandre is good at sifting through that, and I've been marking dev emails with new stuff too, so we should be off to a good start with that. Alexandre?

2. Review all Inkscape window images to ensure the are from 0.47

Definitely. I think it would be beneficial if we could find someone who would be interested in doing only this who is not so interested in writing, both for consistency of images and so we can focus on the content. This is often time-consuming. Any volunteers?

If not, then we only need to focus on the most obviously different ones first, and get the others if we have time. So, basically, add new images where needed, then get the rest after the content is in order. Of course, if you're sick of reading and writing, take some screenshots ;)

3. Once Chapters are complete reviewing them for consistency of a - language b - text style c - image style consistency

Right. I think we have a basic language style *ideal* of precise but not stiff (hard to accomplish sometimes). I like a relaxed description, but it's often difficult to do well in a manual.

I'm not really sure what else needs to be done. I would LIKE to have chapters that go into how to create this or design than, how to put together a group of tools and features when making a creation, a bit like tutorials I guess. However I think the basics need to be completed first before doing the next step and I don't have time right now to start creating such chapters.

The idea of the manual is to present an overview of the application. I think it's important and good to have tutorials, but we've decided to leave this sort of thing out of the manual (1) because there is a team that does tutorials right in SVG files, which is perfect (so you can play around with them) and (2) because, again, the manpower issue.

Let me know what you think as I've not had a deep involvement before I'm not sure of the best approach.

Why don't we start with a list of the new features. We should probably make suggestions as to whether they are to be considered as part of another chapter or their own separate chapter (and which section they'd be under if so).

What do you think?

JF