Adapt Learning Community: Disabling spoor instead of uninstalling it

Hi all,

I was looking at the source code of adapt-contrib-spoor extension (https://github.com/adaptlearning/adapt-contrib-spoor) and realized that properties.schema expects _isEnabled but the Spoor model never makes use of it. The Adapt wiki entry on setting up your development environment suggests to uninstall it if we don't use SCORM.

I would like to avoid the steps of uninstalling and reinstalling it when needed, so would it make sense to change the initialize function to check the _isEnabled property? If it does, I would gladly take this as an exercise to create a pull request as this is my first time working through GitHub.

On a similar topic, I noticed that there are lots of forks from the original repository that haven't been pulled back in for over 6 months (example is cgkineo's fork around June 24th 2014). Is this common/intentional? Won't beneficial features not be included back into the master repository, and won't there be a code gap that'll only grow wider as more commits are made?

Thanks for you advice!

Jerome

Hi Jerome,

thank you very much for your post and for offering to take on this task. It would be great if we could have an initial chat (e.g. via Skype) please feel free to contact me via 'kineosven' on Skype or write to me at sven.laux@kineo.com

I can also answer the questions raised in the last paragraph:

We're currently working on a major update to the framework and are calling that our version 2.0 release. This is not quite ready yet and brings in some major updates to the core. As a result, the other items / forks have not been able to progress much. It's very much the intention that we bring everything together and keep it closely aligned. As you say, the gap would otherwise increasingly wide, which is not what we want.

You can find a bit more info on the release we are working on here.

Hope this helps and I look forward to talking to you.

Sven

Show parent | Reply

Hi Sven,

Thank you for getting back to me so promptly. The information you've provided is very helpful in understanding where version 2.0 is heading and explaining some of the behavior on the repositories. I can definitely start the conversation via email and later chain that into a Skype call.

Best regards,

Jerome

Show parent | Reply

Hi Jerome,

I addition to what Sven says, I'd assume that some (maybe even most) of the forks have been created for the purpose of submitting pull requests, and so can probably be dismissed.

I think with with any open source project there are likely to be a lot of forks created by people who are curious to have a sandbox to play around with code, or to make changes that they have no intention of ever pushing back.

In response to you contributing: please create an issue on the spoor github, and state your intention of fixing it yourself. The core team can then give you any support you may need.

I'm currently in the process of writing up a guide to contributing to Adapt, which you can find on the wiki, but please bear with me, as it's still in the very early stages. On this note: as you're basically the target reader for the page, it would be really useful if you could flag to me anything that you think would be useful as you go along - it may not be written up in time for it to be of use to you, but would definitely be of help to the next person following your footsteps.

Show parent | Reply

Hi Tom,

Thanks for adding to Sven's explanation and also suggesting next steps to action the change I mentioned. I will take Sven's advice and get in touch with him first before creating an issue on the spoor GitHub.

Quickly reading through your wiki page, I find you have some very good high-level topics to get readers introduced to the definition of a contribution, to the profile of a typical contributor and possible tasks. What I usually find useful is task use cases (I want to fix a bug, I want to create a test script, I want to create an extension) with a brief and high-level step-by-step of how to proceed. The step-by-step doesn't have to be full hand-holding, but it can point in the general direction of what a typical contributor should do (fork from GitHub and choose the right branch, make changes, submit issue, create pull request, document on wiki). Please keep in mind that the list I just gave may make no sense since I have never actually used GitHub before. I'm still living in the age of SVN.

If I think of anything else that may be useful in the wiki, I'll send you a PM.

Best regards,

Jerome

Show parent | Reply