Us and them? [was Re: Livecode Dictionary]

[David Bovill]

I'm working on a solution for this - it's kind of ambitious and won't be
ready to share publicly for about 3 months at a guess - but I'm happy to
share it with anyone  who want to use GitHub and get deep into the issue.

*Quick outline of dictionary strategy*

   1. It should be collaborative with the minimal possible barrier to entry
   (wikipedia style)
   2. It should be personal - every user is totally free to write and
   over-write their own notes / take on the content. (decentralised version
   control - aka git strategy)
   3. It should be organised - that is all the version developers use to
   write on, should integrate functionally into the git-workflow editorial
   managed by the mothership.
   4. It should be useful in your own projects and integrated into
   developer workflow - that means the script editor

The elements come together in an architecture where we create personal
project wiki's for the software a developer is working on directly from the
script editor - with wiki pages for projects, stacks, scripts and handlers.
These project wiki's should be self-contained but link to the general
Livecode Dictionary. Should you wish to personalise / write more extensive
notes than available in the "Livecode Dictionary" you can fork teh page to
create your own personalised version.

*Some basic data structure concepts*

   1. The dictionary content should be directly useable by Livecode and a
   web browser
   2. The dictionary content should take full advantage of multimedia
   content including audio and video
   3. The dictionary content should be standards based, work with version
   control, and be capable of things like digital signatures and other metadata
   4. The dictionary content should be licensed with a Wikipedia compatible
   license so that we can mix in Wikipedia and similar content on software
   development

To that end I've decided to standardise on a JSON format - as both the web
browser, and Livecode can process it fast. I use a node project for the
online version, and have a range of tools for publishing directly from the
script editor, and importing Wikipedia content.

*Collaboration and feedback*
Would be great to have feedback on this strategy. My guess is it might not
be clear, and that the only way to effectively communicate it will be a
short screencast. I hope to add that this week, and maybe make a quick
video demo. But the main thing to note - is all the code is open source and
on Github, and the content is all CC-by-SA 4.0
<https://creativecommons.org/licenses/by-sa/4.0/>. The design is to be able
to run it locally, and collaborate online - so you can do your own thing.
Even host a server yourself.

Thoughts? Feedback on this?


On Tue, 22 Jan 2019 at 00:26, Curry Kenworthy via use-livecode <
use-livecode at lists.runrev.com> wrote:

>
> Graham:
>
>  > a conflict between the “everyone can code” philosophy [...]
>  > and the perceived need to be more professional and serious as a
>  > player in the whole software development arena.
>
> Well-said!
>
> Nor should it be assumed that pros and trend-chasers are always
> serious/correct and others are not - I've seen some sloppy "pros" and
> some excellent beginners. People at all levels of software or LC can do
> a great job. (Or not.)
>
> Likewise the trap of assuming that following new trends always brings
> better results. Imagine a Venn diagram between software innovations,
> trends, and another important factor such as quality or efficiency.
> Sometimes or some situations they go together, sometimes not.
>
>  > but it’s not OK if this is at the expense of the kind of user
>  > who doesn’t want to distort the way LC works, for example by
>  > deprecating stacks that contain both scripts and UI elements
>
> I wasn't aware of a plan or push to deprecate those - I don't follow all
> threads, but I emphatically hope not; bad idea! I want LC stacks to
> remain stacks. Easy to use and learn, self-contained, smart.
>
> Git is also smart, very useful for many situations, but not superior in
> all situations. There are trade-offs, just as there are with agile dev.
> Savvy people are aware of pros and cons. Trend-chasers: maybe not aware.
> Good to have both options.
>
> (If this is referencing my own remarks about mixing data and UI for
> files saved at compiled runtime, that's a completely different matter.)
>
>  > cancelling of the ability of these ordinary users to add notes
>  > to the dictionary
>
> Yep, it's worthwhile to keep LC 6 handy for those notes! Highly
> valuable. Continuing user comments for LC 9+ would be a smart move.
>
> Richmond:
>
>  > worrying about Microsoft, if one spends too much time on it can
>  > become fairly unhealthy: and what about Apple, Canonical, and
>  > so on and so forth?
>
> Tribal identity marketing; be careful for people coming after you with
> OS logos and pitchforks, but I totally agree. Tribalism mindset works
> pretty well for group survival, but fails at most other things including
> accurate assessments. Fun social experiment: "MS and Apple are not
> nearly as different as their fans like to think." :D
>
>  > the Dictionary inwith LiveCode to regain its previous functionality
>  > so we can help each other just that wee bit more.
>
> Yep, that would be helpful.
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> "Better Methods, Better Results"
> LiveCode Training and Consulting
> http://livecodeconsulting.com/
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode