Sorry for the bad formatting, used the wrong email account accidentally.
More readable version:
Am 30.04.2017 um 04:47 schrieb Martin Owens:
Even the booktype server of flossmanuals works with automation. Using one of those would also have the advantage that, once set up, this system could be used for both developer as well as user documentation (as Victor wrote in his post - and I agree with him).
Developer documentation is a very different beast and I'd like to if at all possible keep that separate. wiki.inkscape.org is the best location for that at the moment.
- So these are the things I've been basing my opinion on: - we were looking for long-term solutions - the Inkscape Wiki was going to be retired, because it has no maintainer, - developer documentation was going to be moved to the inkscape repo, where developers would see it. - we have limited resources in terms of people who can maintain things, especially infrastructure.
Have there been any changes to these plans? I think /someone/ was even planning to close the Wiki for editing this month...
Having one system that will work for both can significantly reduce the workload involved. Just saying. I know it's fun to devise a new system, and to tailor it to the project's needs. I also know that requires maintenance.
One of the ideas we were playing with, was getting contributors to edit content directly at gitlab.com, then we have a bunch of scripts that consume the wiki git repository, generate pot/po files, and provide the raw resource for an optional secondary step. The second step would be a sort of publishing step. Where we take the content as a specific time, and produce it into a cleaned up, pretty >
book/pdf.
I imagine contributors like CR would be most interested in this step. But everyone would be involved in the raw materials step (writing words and getting screenshots into the wiki)
- I would recommend against using the gitlab Wiki. There are no notifications for it (and no hooks to generate them, as far as I could find out). It uses Markdown (limited, gitlab specific set). It doesn't even have the option of organizing files in a tree structure (yet. May change in the future). The repo is hidden.
I've read a lot about open source documentation in the last months, and the main recommendations from experienced people who tried a lot of different options out, and compared them to each other, were: - don't, under any circumstances, use Markdown, because it has too many custom flavours and is not universal. Use re-structured text instead. - make sure it will always stay portable - make sure you have version control (Gitlab Wiki has, I know. It's only not accessible via interface at all).
- and I wouldn't advise to use a custom solution, because Inkscape's resources in terms of manpower are limited. There exist perfect systems already, which have big communities and are proven to work. Maybe if they can be combined, and just a tiny, editing front-end part is custom (but not a requirement), because that seems to be missing, and would be very helpful for getting contributors.
CC-By would lose that, after the first iteration, as far as my >>
understanding of the licence goes. > > That's not how licenses work (at least not these ones), you can't > remove any prior terms, you can only add terms. Technically you could > take a CC-BY work and wrap it in a CC-BY-SA work, or relicense as All > Rights Reserved. BUT everyone would still be required to attend that > that attribution of the original license. SA means you can't /add > licenses/ to make it more restrictive.
- Thank you! You just filled a huge knowledge gap (:-o).
@doctormo: "FLOSS Manuals utilise la licence libre GPL pour l'ensemble de ses travaux." - translates to: all manuals on flossmanuals are under the GPL (don't ask which version, doesn't say there on that page.
(https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_quest-ce-...
libre-et-open).
Ugh, not dual licensed then. This is where a CC0 or PD would have been better. We can't do anything with the content if we want to use CC-BY- SA since the licenses are incompatible. We'll have to be careful.
- Yes, of course. You've been suggesting to ask the authors... I think they are listening here. Elisa, jazzynico - would you be willing to dual-licence that specific book of yours?
Regards, Maren
Best Regards, Martin Owens > >
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot >
_______________________________________________ Inkscape-devel > mailing list Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >
Am 30.04.2017 um 16:15 schrieb maren:
Am 30.04.2017 um 04:47 schrieb Martin Owens:>> Even the booktype server of flossmanuals works with automation. >> Using one of those would also have the advantage that, once set up, >> this system could be used for both developer as well as user >> documentation (as Victor wrote in his post - and I agree with >> him). > > Developer documentation is a very different beast and I'd like to if > at all possible keep that separate. wiki.inkscape.org is the best > location for that at the moment.
- So these are the things I've been basing my opinion on:
- we were looking for long-term solutions
- the Inkscape Wiki was going to be retired, because it has no
maintainer,
- developer documentation was going to be moved to the inkscape repo,
where developers would see it.
- we have limited resources in terms of people who can maintain
things, especially infrastructure.
Have there been any changes to these plans? I think /someone/ was even planning to close the Wiki for editing this month...
Having one system that will work for both can significantly reduce the workload involved. Just saying. I know it's fun to devise a new system, and to tailor it to the project's needs. I also know that requires maintenance.
One of the ideas we were playing with, was getting contributors to > edit content directly at gitlab.com, then we have a bunch of scripts >
that consume the wiki git repository, generate pot/po files, and > provide the raw resource for an optional secondary step. > > The second step would be a sort of publishing step. Where we take the > content as a specific time, and produce it into a cleaned up, pretty > book/pdf. >
I imagine contributors like CR would be most interested in this >
step. > > But everyone would be involved in the raw materials step (writing > words and getting screenshots into the wiki)
- I would recommend against using the gitlab Wiki. There are no
notifications for it (and no hooks to generate them, as far as I could find out). It uses Markdown (limited, gitlab specific set). It doesn't even have the option of organizing files in a tree structure (yet. May change in the future). The repo is hidden.
I've read a lot about open source documentation in the last months, and the main recommendations from experienced people who tried a lot of different options out, and compared them to each other, were:
- don't, under any circumstances, use Markdown, because it has too many
custom flavours and is not universal. Use re-structured text instead.
- make sure it will always stay portable
- make sure you have version control (Gitlab Wiki has, I know. It's only
not accessible via interface at all).
- and I wouldn't advise to use a custom solution, because Inkscape's
resources in terms of manpower are limited. There exist perfect systems already, which have big communities and are proven to work. Maybe if they can be combined, and just a tiny, editing front-end part is custom (but not a requirement), because that seems to be missing, and would be very helpful for getting contributors.
CC-By would lose that, after the first iteration, as far as my >> understanding of the licence goes. > > That's not how licenses work
(at least not these ones), you can't > remove any prior terms, you can only add terms. Technically you could > take a CC-BY work and wrap it in a CC-BY-SA work, or relicense as All > Rights Reserved. BUT everyone would still be required to attend that > that attribution of the original license. SA means you can't /add > licenses/ to make it more restrictive.
- Thank you! You just filled a huge knowledge gap (:-o).
@doctormo: "FLOSS Manuals utilise la licence libre GPL pour >>
l'ensemble de ses travaux." - translates to: all manuals on >> flossmanuals are under the GPL (don't ask which version, doesn't >> say there on that page. >> (https://www.flossmanualsfr.net/faq-floss-manuals-francophone/ch011_q >> uest-ce-que-lopen-source-et-quelle-est-la-difference-entre-free-
libre-et-open). > > Ugh, not dual licensed then. This is where a CC0 or PD would have >
been better. We can't do anything with the content if we want to use > CC-BY- SA since the licenses are incompatible. > > We'll have to be careful.
- Yes, of course. You've been suggesting to ask the authors... I think
they are listening here :) Elisa, jazzynico - would you be willing to dual-licence that specific book of yours?
Regards, Maren
Best Regards, Martin Owens > >
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ Inkscape-devel >
mailing list Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel