On 9 May 2013 00:27, Yury Katkov <katkov.ju...@gmail.com> wrote: > My answers are inline > > On Wed, May 8, 2013 at 7:54 PM, Dan Bolser <dan.bol...@gmail.com> wrote: >> >> On 8 May 2013 16:46, Yury Katkov <katkov.ju...@gmail.com> wrote: >> > On Wed, May 8, 2013 at 4:04 AM, Dan Bolser <dan.bol...@gmail.com> wrote: >> >> >> >> Hi all, >> >> >> >> I'm afraid I still haven't read the thread discussing LTS and the >> >> clusterf.... resulting from a typical SMW/SF install requiring about >> >> 20 independently maintained but interrelated extensions (it's always >> >> going to be hard!). >> >> >> >> On this topic two ideas came to mind: >> >> >> >> 1) Would adopting this kind of branching model (if it isn't already) >> >> help to improve maintaining stable branches: >> >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> >> >> 2) What can we learn from Drupal development, where multiple modules >> >> are integrated via extensive use of APIs? >> >> >> >> Speaking as a dumb user, can we start a 'developer documentation' page >> >> on smw.org? >> > >> > I like the idea. Still the knowledge about what's happening inside SMW >> > is >> > distributed between 2-4 core developers. They don't have time to >> > describe it >> > and I guess love programming much more than writing documentation. I >> > love >> > writing documentation and tutorials much more than programming but I >> > can't >> > figure out what's happening in the code by reading the code. I'd love to >> > find the solution of virtuous circle. >> >> I guess you saw the link Jeroen posted? >> > The Programmer's guide helps though I meant something like > https://semantic-mediawiki.org/wiki/Architecture_guide but complete and > up-to-date.
OK, how do we incentivise / kick start the production of this content in the short term to yield the long term benefits? >> Many thanks to all the names here! >> >> https://semantic-mediawiki.org/w/index.php?title=Programmer%27s_guide_to_SMW&action=history >> >> To resolve this issue, I'd propose a few group calls to discuss the >> overall code design with one or more 'dockies' making notes and >> working together on 'follow up' documentation and questions for the >> next round. I'm assuming the more we (noobs) get our heads into the >> code, the more we'll be able to decipher. >> >> >> >> I know it's a pain in the neck, but explaining design >> >> decisions to newbs has many long term advantages, not least, forcing >> >> the logic to be explicit helps it to be reviewed 'internally' (by the >> >> developers concerned) and useful ideas may be generated 'externally' >> >> (by the wider community). Making developer documentation should help >> >> attract new developers as well as help users to understand >> >> dependencies. >> >> >> >> >> >> Cheers, >> >> Dan. >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Learn Graph Databases - Download FREE O'Reilly Book >> >> "Graph Databases" is the definitive new guide to graph databases and >> >> their applications. This 200-page book is written by three acclaimed >> >> leaders in the field. The early access version is available now. >> >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> >> _______________________________________________ >> >> Semediawiki-devel mailing list >> >> Semediawiki-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> > >> > > > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
