On Mon, Apr 13, 2015, Jeff Grimshaw wrote: > On Mon, Apr 13, 2015 at 12:27 PM, Adrien Nader <adr...@notk.org> wrote: > > > Hi, > > > > Last year, Samsung contracted a company made of French borkers to > > write its "native application" documentation, i.e. usage of EFLs on > > Tizen. Last week, raster switched e.org to dokuwiki. > > Well, I worked on that documentation and I really like dokuwiki so I > > started porting the documentation. > > > > Yay! Win! Vive les borkers! > > > > It was written as doxygen and we don't have any copyright on that; > > however, the HTML output has been published as a mix of CC-BY 3.0, BSD > > 3-clauses and LGPL v2.1 and Apache. It's not entirely consistent but in > > any case, it's definitely usable (and probably with a better track of > > licenses than what has existed until now). > > > > > Looks like docs are CC-BY 3 and examples are BSD 3-clause. No worries > there.
It depends on parts of the website. It's organized in a complex fashion so it's difficult to keep track of it but I've seen some pages as with other license text. In any case it's something we can re-use. My only worry is that it'll be complex to keep track of and we'll need to say "this tiny is that license, this other, that other license" and so on. Maybe we can limit ourselves to the CC-BY-3/BSD-3 pages for now and make a list of others and when we have a good overview we'll decide how to continue. > > The documentation in Tizen is really good. I'm totally unbiased on > > that. No, really. > > More seriously, it's fairly comprehensive and covers some topics which > > are large enough for no-one to deal with them on their free time. > > > > It's made of "tutorials" and "programming guides". Programming guides > > sit between tutorials and the API reference. Think of the tutorial as > > "hold-my-hand-and-make-me-use-that-widget-for-the-first-time" while the > > programming guide explains the common APIs and usage. Most widgets are > > covered. > > > > For reference, my first try is a page with no incoming link at: > > https://www.enlightenment.org/docs-non-api-wip > > > > This page "does not exist yet" for me on the wiki :-( Hmmm. I did the edit with another computer which is currently sleeping in a backpack so I can't guarantee the address but I'm fairly sure it was working. Maybe someone deleted it. Anyway it wasn't very valuable (some kind of experimentation). > > The very first question I got was: how do we organize that > > documentation? > > Dokuwiki supports namespaces and we probably want to take advantage of > > that; namespaces can appear in the URI either as "foo:bar" or "foo/bar" > > and it's also possible to put a page directly at "foo". > > > > I think we could have namespaces and pages like: > > doc/ > > doc/efl # lists and explains libraries > > doc/efl/ecore/ > > doc/efl/ecore/events # covers events, their handling, the mainloop... > > doc/efl/elementary/ > > doc/efl/elementary/concepts > > doc/efl/elementary/widgets # nice, sorted, widget gallery > > doc/efl/elementary/widgets/button # page-name is guessable from the API > > doc/e17/ > > doc/e19/ > > > > Any thought? This really seems like the most blocking aspect to me. > > > > This sounds sane. I don't have any experience with dokuwiki (yet) but > namespaces > sounds like a good way to organize the content. Is it easy to move if the > organization > does not work out? Any problems linking between namespaces? Dokuwiki uses a simple file-and-directory storage for data. This means that the above will be on disk as: doc.txt doc/ (a directory) doc/efl.txt doc/efl/ doc/efl/ecore.txt doc/efl/ecore/ doc/efl/ecore/events.txt ... There's no namespace containerization. Linking happens in the same namespace by default but it's easily overriden: from doc/efl/ecore, write [[:doc:efl]] and you get a link to doc/efl.txt. It's possible to move files by hand if needed. The only annoyance is that the tree structure is duplicated in two other places: the cache and another one ("meta" iirc) but moving is also possible there and there are scripts for that. It also doesn't seem too difficult to fix links afterwards. > > A few more things (most are for the wiki admins). > > > > What's missing or could be improved: > > - the dokuwiki "syntax" page cannot be found on the wiki; it's a problem > > because some dokuwiki plugins extend the syntax and it's difficult to > > know which ones are enabled without that page > > - there should be a plugin which provides mediawiki's table/list syntax > > (there are several of them available, not sure which one to chose) > > - locating the words "tizen" and "appcore"/"app_core" is fairly > > difficult and it'd be nice to have highlighting for that > > - when I want to upload an image, I need to download it locally then > > re-upload it (something for which I don't have the rights it seems) > > - we need to think about the license a bit in order to have something > > compatible with the mix from tizen.org. > > > > Can we just keep the same license scheme as tizen? I like the mix of CC-BY > and BSD. Very simple. I'm all for it. The only potential issue is if "upstream" tizen has something else. -- Adrien Nader ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
