Any ideas about creating an open source Inkscape Manual? Kind of like wikibooks.org, where the community is allowed to make text edits. And images, in our community better referred to as graphics, must to be reviewed by an admin before allowing the graphic to be added to the book.

We need a comprehensive, new to graphics based beginner's manual. If you take the time to research on a beginners guide to Inkscape you'll come up empty handed. Instead what I find are quick tutorials about distinct creations. And existing manuals are all written with verbiage leading one, that is not familiar with graphic editing, a bit of a tough path to learning the world's best vector graphic open source editor, INKSCAPE!!

Suggestions on a path for us to begin this effort?

See http://en.flossmanuals.net/inkscape

Also do a search on the documentation mailing list to find out more (sorry, got to go in a minute).

vwanweb wrote:Any ideas about creating an open source Inkscape Manual? Kind of like wikibooks.org, where the community is allowed to make text edits. And images, in our community better referred to as graphics, must to be reviewed by an admin before allowing the graphic to be added to the book.

Requires a community with several volunteers, "quality check", a full time admin and maybe an own site too.
As far as own site goes the inkscape board would probably be fine with it.
Quality content? Lets do it already and host each page at openclipart as public domain...

Okay, longer version now (still in key phrases, it's easier that way):

- There is a loose aggregation of people who said they would help working on a manual, but cannot do it alone. These can be reached via the documentation mailing list for Inkscape.
- There is already a general consensus that it would be smartest to not start from zero, but from one of the existing manuals.
- The official manual by Tavmjong Bah is non-free and cannot be edited, it's kind of a dead end.
- The flossmanual linked in the post above is free and can be updated and edited by anyone anytime, and is a good starting point, in my view.
- There isn't currently anyone who has the time and energy to coordinate such an effort. Elisa de Castro Guerra once said she would help with a doc sprint.
- The English version must come first, then translators need to be activated.
- We will definitely need reviewers, and people experienced in writing documentation to check things.
- The format that is chosen should be chosen to allow to create books, html pages, and pdfs easily (like it's already the case with flossmanuals).
- We cannot copy-paste from Tav's manual, for copyright reasons.

- Many tutorials are not so bad at all. Just look at the comprehensive series by Mark Crutch in Ubuntu Full Circle magazine and the introductory tutorials that are included in Inkscape (or even my 'Inkscape for Noobs', see linked website in signature).

vwanweb contacted me via PM, where I've given him an overview of the current state of discussions. But it seems he has a nice surprise for us...or maybe 2. I'll let him decide when or whether to show them.

Lazur wrote:Requires a community with several volunteers, "quality check", a full time admin and maybe an own site too.
As far as own site goes the inkscape board would probably be fine with it.
Quality content? Lets do it already and host each page at openclipart as public domain...

Yes, a lot of people are more than ready for this! And there are a lot of people (relatively a lot) who are ready to start writing. We just need someone who has time, motivation, and is willing to take the lead. I could do that, but not right away. I'd need to finish other projects first. I'm not sure if vwanweb wants to take the lead either. But as I've suggested to him, along with subscribing and posting to the Docs mailing list, perhaps the first step is to put together a list of everyone who is ready to write. At least create that "official" team.

Not sure if a team leader would need their own website. The Docs mailing list is perfectly suitable for communications. And apparently, developers prefer that type of communication. I suspect the people who currently are in charge of documentation (Tavmjong Bah, and JazzyNico, I think) simply just don't have the time to start such a project. However, I can't think of any reason why they would be opposed to it. Using the Docs list for communication, allows them to stay informed, without having to spend tons of time. I've learned how easy it is to get things moving, if I start on the mailing list (as much as I dislike mailing lists, lol).

Just so vwanweb can get some idea about that 1-chapter French FLOSS manual, Moini, could you post a link to it? I'm in a bit of disarray with email at the moment, trying to set up a new computer fast, before this one dies completely (is half dead already - allergic to safe mode, lol). I can't seem to find that link.

It's quite a bit longer than 1 chapter (but in French, and I think Sylvain is working on translating it to English, no idea of current status, though):

https://www.flossmanualsfr.net/initiation-inkscape/

Thanks, Moini

Oh, I've always had the impression it was just an introduction chapter. Apparently I misunderstood. It will be interesting to see it in English.

Thanks for the replies. It seems floss manuals is a for profit publication site. I would like to try to steer away from any for profit establishments, due to the Inkscape's 'Draw Freely' motto. Even though the community can edit floss manuals, wikibooks.org nearly has wide open doors when it comes to community based creations. And the download as .pdf widget can be applied to wikibook.org manuals, not possible at floss manuals.

Even though Inkscape.org has its own wiki enabled site, ease of access is not there. I have been trying to find out how to 'join' the Inkscape Documentation team, but come up empty handed. Additionally the Inkscape wiki.inscape.org domain does not have an open source equivelant to wikibooks.org. Hence this is why my current efforts lay onto the wikibooks.org domain.

I just reviewed the floss manual and one of the issues that would be minimized by having a wiki based approach, is that it has very outdated information and is not current to the latest stable v0.91 Inkscape release. If you go to pages 143 thru 148 of the manual you will see that a majority of the content in the manual is from 2008 and 2009, with only a few made in 2010. In the past 6 years Inkscape's developers have delivered significant enhancements to the software, we need to catch up and get the user documentation up to speed with a wiki based approach, your thoughts?

-vwanweb

Well, the Inkscape wiki would not be an appropriate place for a manual, because it is being groomed as a developer's resource. All the user-related info from the wiki either already has been moved to the website, or has been overlooked, and needs to be moved.

Anyone can get access to the Inkscape wiki, by subscribing to the development mailing list, and asking for an account. But again, it is now primarily a developer's resource.

I explained about this Documentation "team" in my reply to your PM. It is a very loose and vague group which is aching for someone who has the time and motivation, to bring it together and focus it on certain tasks which need doing, such as a manual that we've been discussing, which would teach Inkscape in more of a step by step way, and is less theoretical than the current manual; and such as additional official tutorials (the ones in the Help menu). Subscribing to the Docs mailing list essentially puts you on that team. But just subscribing to the list will not get things moving, since the main problem is the team needing a leader. Or co-leaders. While I couldn't volunteer to be such a leader at this time, I could be a co-leader, at least until I finish my other commitments.

I didn't realize the FLOSS Manuals was a for-profit site. But I did see that Inkscape book authored by FLOSS Manual editors, that's for sale, when I was trying to find that French manual. It seems a little odd for it to be for-profit....there must be some "catch". It could be a non-profit group, if the book sales were tax deductible (i.e. donations). I'm trying to find some explanation on their website, but haven't found it yet.

Nowhere can I find any kind of info about that. It doesn't call itself non-profit, but it doesn't call itself profit-making either. All I can find is it's called a "Foundation". Aah, finally! Wikipedia calls it a non-profit foundation https://en.wikipedia.org/wiki/FLOSS_Manuals Seems like their website could serve them better, by specifically calling themselves non-profit.

Well, I don't understand the selling of books. But they do seem to be non-profit. I guess even non-profit groups have to have some kind of income. They just can't show profits. The Inkscape project has recently set up some new guidelines for things like crowdfunding. So just being open source doesn't divorce a project from needing income, from one place or another. So if the FLOSS manuals can be sold as books, as long as they don't show a profit, it's legal.

Regarding the FLOSS content being outdated, anyone can register and start updating it. Why haven't they? I don't know.

How do you think a wiki-based approach would prevent a manual having outdated info. Both the wiki and FLOSS depend on volunteers to do the work. I would guess a wiki-book could become outdated just as well as the FLOSS manuals, if no one bothered to keep them up to date. I don't mean to be argumentative. I'm just curious why you think a wiki book would be less likely to have outdated info.

We need a "Document what you Do, Do what you Document" approach to close the Developers to Documenation gap. With all due respect if this was a commercial operation. Inkscapes efforts would be approached in a HUGELY different way. Think of release 0.91 being delivered in a commercial environment, the developers hand the documentation over to another team and work in union, with no stagger between the two teams. So when the stable software version is "released", in tandem the latest documentation is also "published".

In my opinion, this tandem approach would benefit inkscape monetarily as well. Hit the pause button and think about this if you release a new product, but do not release documentation in tandem with it, the product will lag. But if one releases both in tandem then a best effort is refelected to the consumer and the lag will be reduced, right?

Once Inkscape hits full SVG2.0 compliance then there may be a percentage of academic non-profits that would benefit greatly from this, if a corresponding open source manual was published when the software was released. The junior high, 7th grade teacher would have no reason not to, at a minimum, at least inform his or her art students about the Inkscape release. The following conversation is more likey to occur if the two (software/book) were in tandem with each other; 12 yr-old student from a 3rd world location "Mom I am taking a graphic art class this semester and the software and manual are both free, the software is called Inkscape" Mom replies "Great honey you have always loved to draw and Inkscape is awesome for making it free".

Well, of course that's the ideal scenario. I totally agree that it would be a great benefit to have documentation that's always up to date. I'm sure that the entire community probably agrees. But we are limited in what we can accomplish, here in this forum, because developers don't visit here (except for a very few, and lately, those are rare visits). This discussion needs to be had with developers, if we hope to change the status quo.

It's not that we're totally helpless as users. You've accomplished quite a lot, all by yourself. Certainly we could contribute to documentation! But if you want documentation and hacking happening at the same time, which will be a change in the way development happens, you need to address the developers.

Can you suggest a way this could be accomplished? Once you approach developers with this concept, probably one of their first questions would be - how do you propose this could happen?

I suggest that you subscribe to both the Docs and Devel lists, so you can communicate directly with developers. (And maybe the Users list too, if you like to help other users.)

You could also search Launchpad to find out if anyone has started a feature request about a different kind of manual. Maybe find more interested people that way....maybe find more new ideas too. And it seems like I've seen something in the wiki about a new manual. So the wiki would eb worth searching too.

This article is about middle school 7th graders (12 yr-olds) taking 40 minute classes for graphic design using Inkscape, published in 2010:
https://opensource.com/education/10/4/i ... dle-school

here are a few extracts from this article:
"John secured a budget to supply Blanchard with 10 Wacom Bamboo Touch tablets"
"The first class was a bootcamp-style introduction to Inkscape - we went through various essential basic Inkscape tasks one-by-one"

Here are the links to lesson 2:
http://linuxgrrl.com/learn-wiki/images/ ... esson2.pdf
http://linuxgrrl.com/learn-wiki/images/ ... rcises.pdf

One of the reasons for posting this here is to show that Inkscape is in classrooms and the teachers had to dig into to multiple manuals to create their lesson plans, why not create a tandem wiki based manual and add an appendix tailored toward educators.
Appendix 1:
-Lesson plan X
-Exercise X
-Lesson plan Y
-Exercise Y
Marketing is not restricted to for-profit organizations, tandem documentation publication when software is released is a basic need.

-vwanweb

I didn't read everything up to here (too much for today), but I just want to note that flossmanuals is not for profit. It produces CC-By-SA contents. What they are trying to do by selling books in a printed format (you can download everything easily as pdf) is to get the money they spend on providing the server capacity and site administration back (and I don't think they do).

You can find info about how to join mailing lists at http://www.inkscape.org/mailing_lists.html

Still I think updating an existing manual is a lot less work than writing a new one - you will find people who help you with that task more easily. I probably wouldn't help with a new book, I do not have the time for this kind of duplicated work. I'd rather write my own one in German

You cannot force the devs to do the documentation. It just doesn't work - they are volunteers, and while they would most certainly also like to have their work documented, they have to decide between investing their time into programming, or into documentation - and as there are many people who could write documentation, but few who can program, I sometimes think it's better they invest into programming. It's totally possible to approach a programmer about a new feature they added, ask them to explain, then write it up.

Please read up on the related discussions on the mailing lists to get an impression of the current status.

Using the development version and documenting everything new one finds, and following the commits on launchpad to find out what has changed, is another option to get the info one needs for documentation. Unfortunately, some features are taken out before a release, because they aren't stable enough, or cause other difficulties, so it often doesn't make a lot of sense to write documentation before a release...

For an overview, you can take a look at the release notes. They aren't complete, but the most important points are there: http://wiki.inkscape.org/wiki/index.php ... notes/0.91

Things move slow in open source development, people do not all have the amount of time available they would like to have (and many feel guilty about that), and pressuring people will result in them just ignoring you.

Moini wrote:Many tutorials are not so bad at all. Just look at the comprehensive series by Mark Crutch in Ubuntu Full Circle magazine and the introductory tutorials that are included in Inkscape (or even my 'Inkscape for Noobs', see linked website in signature).

It's worth noting that my articles are released under a Creative Commons Attribution-Share Alike license (see the footer on the contents page of the magazine for full details).

Although I don't have the time to get involved in a documentation project, you can use any of my existing articles under the terms of the CC-BY-SA license, even if only to "fill a gap" until proper documentation is written for a given part of the manual.

The "share-alike" part of the license may be a problem, depending on where the files are kept and the license of any associated documentation. I'm happy to drop it, but would need to seek approval from the editor of the magazine first. I can also supply my original LibreOffice documents, which would likely be a better starting point than copy-pasting from the magazine PDFs.

I'll hold off doing anything at the moment. Once there's a more definite plan, if it's felt that it would be useful to reuse any of my articles then I'm happy for a representative of the documentation group to contact me to take this further.

@Mark: I like the licence and would see it as a waste of time to work on anything that isn't 'Attribution and Share-Alike' (or equivalent).

Moini wrote:@Mark: I like the licence and would see it as a waste of time to work on anything that isn't 'Attribution and Share-Alike' (or equivalent).

I like it as well - but my concern was that it could "taint" other parts of the documentation by requiring them to be released under the same license. If all the documentation uses CC-BY-SA then it's not a problem, but if there is a plan (or requirement) to use other licenses, even if they are broadly equivalent, then you would have to at least isolate any content derived from my articles into stand-alone units whose license wouldn't impose a requirement on other units. Dropping the "share-alike" (if the Full Circle editor grants it) would allow my articles to be mixed more freely with other documentation that may be under a different license.

But it's pretty academic until you actually need to pull something from my articles into the documentation. I'm offering my work as a communal resource which is already under a reasonably permissive license, mainly to avoid "dead spots" in the first pass at a community manual, but the "tutorial" style may not suit a "manual" anyway (compare my waffling pages of prose with the concise definitions in Tav's existing manual, for example).