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.
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
