Us and them? [was Re: Livecode Dictionary]

[Brian Milby]

Two comments initially:

That license will not allow inclusion into the LiceCode dictionary as it requires any derivative works to carry the same license.  For integration into the LiveCode project a CLA will need to be signed by each author and their contributions also submitted with copyright assigned to the company.

The dictionary uses markdown as the source format.  To be easy to integrate, it would be a good idea to use that as the storage/native format of contributions.

Sounds much more ambitious than what I was thinking about (trying to figure out how to leverage the TinyDictionary notes feature for collaboration).  Looking forward to seeing more.

Thanks,
Brian
On Jan 22, 2019, 6:20 AM -0600, David Bovill via use-livecode <use-livecode at lists.runrev.com>, wrote:
> 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
> _______________________________________________
> 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