ebbinghausIllusion

[joshkenney]

Ready to push my ebbinghausIllusion task.

[pjkohler]

You mentioned here https://github.com/jspsych/jsPsych/discussions/1575#discussioncomment-440088 that you made your repo a submodule in your clone of experiment-demos. Does that not mean that experiment-demos will remain dependent on your ebbinghaus repo? I don't think we want that.

You should make a branch of experiment-demos, and the add your ebbinghaus experiment in a folder at the top level. I think?

/Peter

[joshkenney]

I've done that - I have a new branch (ebbinghaus) ready to push and the task is a submodule at the top level.

Wouldn't we want all tasks as submodules? An aggregate of tasks constantly updated by the task owners?

That way, when I make a change to ebbinghaus, those changes will be available in the experiment-demos via the submodule. Makes for code that is more DRY. I'd rather not make changes in two places

[pjkohler]

I see your point re. submodules but I envisioned a model where each new addition was tested / checked, and that becomes difficult to manage if authors can add new changes that would be incorporated in the experiment-demos repo whenever they please? I also didn't really think that experiment demos would be under ongoing development - after all, these are meant to be classic experiments / effects. If you do make some groundbreaking change that you want to incorporate in the "public" version of your demo, you can always do another pull request. Does that make sense?

[pjkohler]

Put in another way, I envisioned that it would work the same way as it does for contributions to the main jsPsych branch. Once I have contributed a plug-in via a pull request, I am no longer free to update the jsPsych version of that plugin, unless I make another pull request.

[joshkenney]

Thanks Peter - I appreciate your insight and for sharing with me how you are conceptualizing the development process for the repo.

If you view this repo as a sort of submissions portal, wouldn't you want to insure that changes are making their way back to the submitter's original repo? Submodules will also do more to restrict unwanted changes making their way into someone's code without their permission, as pull requests can be submitted to the task owner directly.

Perhaps my take on this repo is larger in scope: a fledgling community of jsPsych developers who have something of value to share and want their code to embrace standards that will make all jsPsych tasks have a common feel - making them easier to pick up and use, easier to collaborate on, and easier to fork into new experiments. I'm envisioning whatever momentum we create will attract others to the platform and by extension grow our open-source community of jsPsych developers.

Further, I see this repo as different from jsPsych in that there is no singular codebase that we are maintaining. Since I have the habit of refactoring my tasks once every 2 months or so, it is inevitable that changes will occur. Nothing is every really "complete" for very long. Incorporating a groundbreaking (or even minor changes) between two codebases can be...painful. Just trying to avoid that sticking point.

Does this make any sense? Obviously, I don't want to step on anyones toes - I just want to offer my 2c.

[jodeleeuw]

Throwing my thoughts in here, but I don't want to turn into the de facto decision maker.

I think it is useful to think of the tasks in this repo as not belonging to any one particular maintainer, but rather as part of a collectively maintained set of examples. Otherwise we run the risk of great examples needing to be wholly replaced when a particular person is no longer actively managing the corresponding git repo.

I also think having PRs go through an approval by the maintainers of this repo, rather than a task-specific repo, will help enforce a reasonably cohesive code style across these tasks. I don't think the coding style needs to be identical. Seeing different approaches can be useful for learning. But in so far as any jsPsych best practices exist, it will be easiest to encourage their use in this repo with PRs going to the repo itself.

I do hope that there will be multiple maintainers of this repo so that this kind of decision making is more distributed.

[pjkohler]

Yes, that is my thinking as well. This would leave the contributors of this repo free to develop and maintain the experiments in the repo independent of the original contributors, and the original contributors would likely be free to develop their own versions further, and share those changes with this repo when appropriate (through additional pull requests).

[pjkohler]

As far as sharing every developers individual repo, like the submodule model suggested by @joshkenney, I wonder if this could be accommodated by maintaining an list of repos with experiments under ongoing development, that owners are interested in sharing with the community. Such a list would be uncurated and totally open, whereas this repo would be (somewhat) curated and contributed experiments would be subject to approval.

[joshkenney]

Thanks everyone for jumping in. I really like @jodeleeuw's idea of an approval process. Just one question: what is a PR?

I was also thinking that access to the repo could be controlled by the contributor list. In return for contributing and maintaining a new task, all contributors would have access to the tasks inside the repo.

I work a lot with submodules and find them super useful. I'm not as familiar with pull requests. @pjkohler, I'll try making a pull request tonight. Lemme know if issues.

Usually, I give collaborators access to my repos and we push and pull from our local branches and that is more than sufficient for smaller projects. Perhaps a hybrid model, where we incorporate submodules and pull requests, would work well in this case?

[pjkohler]

I assume PR is pull request.

I was also thinking that access to the repo could be controlled by the contributor list. In return for contributing and maintaining a new task, all contributors would have access to the tasks inside the repo.

The tasks inside would be accessible to anyone. Do you mean access to maintenance? Not sure about that, if we get as many contributors as I hope we will, making all of them maintainers would be too many.

I work a lot with submodules and find them super useful. I'm not as familiar with pull requests. @pjkohler, I'll try making a pull request tonight. Lemme know if issues.

I see your pull request. Will take a look soon, stay tuned.

Usually, I give collaborators access to my repos and we push and pull from our local branches and that is more than sufficient for smaller projects. Perhaps a hybrid model, where we incorporate submodules and pull requests, would work well in this case?

What are you proposing we use submodules for in this repo? Still not convinced it is a good idea for the purposes of this repo.

[pjkohler]

@joshkenney: I took a look at your PR, and it looks like you are trying to merge a submodule. Please remove the submodule from your branch, copy over the relevant files from your original repo to the branch, and push them to the branch. Then we can continue the process.

[joshkenney]

I see, you don't want the repository to owners to have to approve the pull requests - you want the pull requests controlled by the repo.

I think that makes sense for this purpose. If this repo's scope was widened to task sharing/hosting, we would certainly want to use submodules. I'll submit a new PR like you suggested.

Thanks!

[joshkenney]

@pjkohler submitted a new PR, should be all set now