how do people get colleagues to be better about using/approaching git + GitHub? e.g. have two metadata colleagues who are trying to run scripts I wrote them, but don't ever pull down latest changes (with bug repairs after they report back) before rerunning, then blame the script (+ not the whole process).

@cm_harlow Two things:

1. You may need to improve the way you're communicating that fixes are in place. They can't be expected to just _know_ you've published a new version.

2. If you're doing 1., it's just a matter of repetition. Every time they say "it's broken!" say "make sure you have the latest version. Go to Github."

@cm_harlow repetition. Drill it into them. There's really no other way.

@deagle i've been telling them via email, in person, tagging them in the issues / discussion on the PRs.

@deagle i've also run internal workshop on using git/github (as to not target anyone but also say 'here's a branch, here's a PR, here's how to pull latest changes, etc.' + wrote those up as shared docs

@deagle i do think there is obvs something with the way I'm communicating, I just don't know what.

@cm_harlow Depending on your organization and your comfort level it may be appropriate, after enough repetitions, to say "I can't help you until you've gotten the latest build. Please let me know you've done that before sending a question" - in some orgs this may be unacceptable, culturally.

@cm_harlow Also, can you solve a people/process problem with Technology? can you make your script check its version against Git and fail with an obvious error if it's outdated?

@deagle i've been working hard on refactoring a lot of our scripts/code for existing tools to have unittests (most of what was handed to me didn't)

@cm_harlow it's a little brute force, but if the output data can't be ingested, send it back to them and remind them to use the new script?

@etradio1 yeah, honestly, i already do that. these are scripts though that don't lead to output handed off to me (i just fix the errors down the line when they reappear in my repo assessment cron jobs)

@etradio1 or they lead to complaining on various internal listservs of having to redo manually (which they don't have to do but you know?)

@cm_harlow ooof yeah, i know. it's one of those things where you really need a critical mass of people for it to become part of the culture or it just fizzles. i guess you can really only put sticks in the mud one at a time.

@etradio1 i thought the internal workshops would help with this - help get people a lil more comfy, see the value, etc. but metadata folks didn't show up, dang it

@cm_harlow isn't that how that is supposed to go? target an audience and wait for everyone but them to show up? maybe invert the workshop!

@etradio1 ha maybe! we did get some rad pickup from folks in digitization + in archives, so it was a win in its own way

Sign in to participate in the conversation

Everyone is welcome as long as you follow our code of conduct! Thank you. is maintained by Sujitech, LLC.