Mike Kerner wrote:
The process for modifying code and the process for modifying documentation
should be different.
I agree that's it's very valuable to continually strive for ever-better
workflow methods.
The challenge here is: what exactly does a better solution look like?
Even if we decide we don't want to use Git for part of the product, the
rest of the product is maintained in Git so we'd then have the
additional task of creating some means of integrating the new system to
allow tracking and building within Git.
This is not impossible. But it is also not trivial. That much is known.
What's unknown is whether that additional work is more or less work than
working within Git.
Anyone who came come up with a solution that answers that question
favorably in terms of cost-effectiveness will be a hero.
Git, maybe intentionally, makes it difficult for people to work together
on documents. One of the things that Ali and I ran into is that he
cannot easily make changes to my changes because that's not the way
git is designed.
I'd need to learn more about the specifics of that particular moment
before I'd feel comfortable charactering Git as not being designed for
collaborative workflows. Indeed, Git's support for collaboration is the
main reason people deal with its funkiness in other respects. :)
And I'm in the wrong branch. I won't be the only person to do that,
either.
Yep, I've done that. Happens, in any system that supports branching.
Such an error is similar to the fact that many thousands of people will
have automobile accidents today. No one wants an automobile accident,
but it's easy for humans to make mistakes. We all have a lot going on.
Documenting how branching works can help, but then admittedly it adds to
the knowledge one needs to acquire in order to help.
Perhaps this may reduce some of the overhead with contributing:
If git is going to be the tool, then there needs to be a pre-tool.
...
On Wed, Apr 13, 2016 at 10:42 AM, Richard Gaskin wrote:
...
Maybe this is an opportunity to raise the bar, for both Git and LiveCode,
to serve our own needs while showing the world how awesome LiveCode is:
Many years ago Ken Ray made a marvelous stack called Revzilla, a LiveCode
plugin that served as a front-end to Bugzilla. At the time many found
Bugzilla's cumbersome UI off-putting, and Revzilla provided a way to submit
and review bug requests that was much simpler and more convenient.
(I don't think it's been maintained through the last two rounds of LC's
Bugzilla overhaul, but FWIW Revzilla can be downloaded here:
<http://www.sonsothunder.com/devres/livecode/downloads/RevZilla2.htm> )
I wonder if the power and flexibility of LiveCode could be applied to
making a front-end for working with LiveCode documentation.
It would of course be ideal if the core dev team had time for that, but
looking at the queue of things I'd like them to do and things others want
them to do I can't say I'd want that to be a priority for them.
And ideally it needn't be. After all, the one thing we know about the
LiveCode community is that everyone in it knows how to program in LiveCode.
I could contribute to such a project, but I have to be realistic about
time commitments and admit that I can't take a lead role on that.
But just maybe someone here has the intersection of time, skills, and
interest to consider it.
If so, I'd be happy to help where I can.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
