Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: MATLAB Live launch buttons for tutorials #546

Open
2 tasks done
bendichter opened this issue Sep 26, 2023 · 6 comments
Open
2 tasks done

[Feature]: MATLAB Live launch buttons for tutorials #546

bendichter opened this issue Sep 26, 2023 · 6 comments

Comments

@bendichter
Copy link
Contributor

What would you like to see added to MatNWB?

see title

Is your feature request related to a problem?

No response

What solution would you like?

see title

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

@lawrence-mbf
Copy link
Collaborator

@bendichter
Copy link
Contributor Author

No, I mean a button in the README to launch a free MATLAB cloud instance with that tutorial livescript file loaded and ready to run. I'm not sure if this is possible but worth a try

@vijayiyer05
Copy link

@bendichter If it helps, I'd be glad to give a demo of other toolboxes using Open in MATLAB Online for tutorial examples as you describe. So long as the data size is manageable, whether as part of repo or accessed via S3, I believe this should work well for MatNWB.

@bendichter
Copy link
Contributor Author

@vijayiyer05 that would be great. In fact, there is no source data so this should be quite simple to set up.

@ehennestad
Copy link
Collaborator

ehennestad commented Jul 6, 2024

Example here:
https://github.com/NeurodataWithoutBorders/matnwb/tree/546-add-live-launch-buttons

Added a "Open in MATLAB Online" badge in the beginning of the readme as well as two "run in matlab online" links on the tutorial list.

@bendichter
Copy link
Contributor Author

bendichter commented Jul 7, 2024

@ehennestad this is great!

Would you mind going through our standard workflow for changes? That would be:

  1. File an issue (this was done already)
  2. Create a new branch that addresses the issue (as you have done)
  3. Create a PR that merges into master
  4. In the description of the PR, write "fix #546". This is a keyword for GitHub to automatically link the PR to that Issue. When the PR is merged, the Issue will be automatically closed. Only right "fix #[num]" if you think the merging of this PR truly concludes the issue. If you want to link it but not close it, you can write something like "related to #546". This will create a bi-directional link without the automatic closing feature.
  5. Assign another developer (e.g. me) as a reviewer. I am a good person to choose esp. for issues I raise or for documentation-related issues like this.

I know this can kind of be a bit onerous, especially for smaller PRs like this, but it helps us manage many PRs as a team across a lot of repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants