Volunteer github guru for documentation submissions?

Richard Gaskin ambassador at fourthworld.com
Wed Apr 13 12:39:25 EDT 2016


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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list