On Mon, 3 Sep 2018 at 09:58, Markus Krötzsch <mar...@semantic-mediawiki.org>
wrote:
> I have asked this questions myself a lot when I was still the person
> that got such emails, and I have to admit that I do not have a good
> answer. The transition from a super-tiny/one-person dev team to a small
> size team (with a plan, and processes, and everything) seems very hard.
> I think the natural way is that new devs arrive to help with something,
> get increasingly familiar with the code and core, and at some point are
> part of a growing team. It seems this is not happening with SMW, and it
> would be interesting to know why. Most obviously, PHP/MediaWiki coding
> is not super appealing. But it also may have to do with the extension
> model of SMW and MW: motivated fresh developers tend to make their own
> extension rather than joining another project.
>
I've been using SMW for quite a long time, including a few current sites. I
still find it a standout solution for many settings, bringing together the
tools, content development and culture cues of MediaWiki, the incredibly
practical and relatively easy to work with Page Forms, the very helpful
community, and of course the underlying facility of triple-based data,
querying and views and connected perspectives. However, as Markus
identifies, even though I'm a full-stack developer, I really haven't been
drawn into PHP, and my perception of it as someone who only works with it a
few times a year is it's a heaving mass of legacy and very current
approaches, from the required PHP version itself, language features used,
the Mediawiki hooks, composer (nothing but trouble when I've used it), all
the extensions, and the approach to Javascript (jQuery? in 2018?), as well
as the developer culture of MW/SMW with approaches often very different
than other developer worlds.
It would take a lot of dedication and support to become a good MW/SMW
developer, but most people (like myself) have to fit our work into other
main goals. My approach to manage and enhance sites is often to use
/api.php and Javascript (on the command line to manage content, and in the
browser to make sites more user friendly), bypassing the general MW/SMW
stack. In particular I'm developing frontend enhancements using React, with
all the facilities of a current Javascript stack, which in many cases works
very well and I'm quite excited about its development.
Even though I follow this list, I don't have a very good idea of what's
involved in SMW 3.0 and how it would affect projects I support. From a
"pain points" perspective, I would dream of a way to integrate on the
server using node.js with an essential API to avoid the latency of api.php,
do server-side rendering and shared js processing, and introduce new
abilities (fine-grained permissions, class validation? j/k). I guess done
well that could be a way to inject new life. I would also make the
perennial request of understanding how Wikibase fits into all of this,
since it is "the fulfillment of the original dream of Semantic MediaWiki"
and might be a chance to make the stack more friendly to non-technical
people. While I focus on knowledge transfer, most users don't feel
comfortable doing data management.
After writing this I realize I'm not adding much for the actual developers,
but I'll post it anyway to see if the Javascript angle in particular has
any interest.
David (but not David Schor)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
