DivaVocals:
:laugh: I'll have to read and try and digest this all after I eat.. I already submitted the pull request for my changes.. (figured out that I missed this all on my own..:smile: just need someone to tell me if I did it "right":smile:)
In summary my changes included deleting the outdated v1.4.1 jQuery file that is included with Zen Lightbox in it's entirety, and replacing it with a NEW file that instead pulls the latest version of jQuery from a CDN.. (I followed the same pattern that Picaflor follows in her templates)
Now going forward should I have simply worked from Design75's repo or niestudios's original repo versus creating my own fork???.. As I said I know what gihub is for, but have never used it in practice.. So I simply followed Design75's lead and created my own fork.. If this was the wrong path, then I would appreciate some tips on best practices here..
If you and Design75 are working on the same "goal" then probably better to repo/fork off of Design75's version so that the changes made by the two of you could be merged together by one of you and then brought into niestudio's master. If you each are working on something different, like each working on a different feature, or "black box", then repo'ing off of a functional path would be best/easiest. In short, the collaborative effort actually requires collaboration, not just at the software level (which allows "checking out" each other's work), but also in the communication of what is being done to minimize rework and duplication of effort.
Also, by forking off the master, the master can be changed, including building more functionality, and eventually the or one of the forks can be merged with the master (possibly to even create a new branch) to verify downstream/future compatibility, and then could be rewound also to find in which commit caused a conflict.
I personally thought it was great to see you run off and give it a shot. Unfortunately you and one other basically did the same thing, so the result didn't give you the best first experience. :)
In short, usually best to pick a "known" point that is good/works (which you can do before actually forking the project) and then work from that point. When others provide input, always possible to provide comment associated with what they have shared with github/the thread "runner". (That person also can add others to help manage the master thread.) Also, there are ways/places to provide input about the mod as part of pushing each commit, and depending on your interface software this may be "clearer" than with others, but generally the title will wrap around to the body of the statement(s), also things pushed to github, well... are out there and can not really be taken back. There are several readme files in github that are informative. Perhaps niestudio may have other hints/tips?