Tool for GitHub commits in browser

[rlanzafame]

Short version: in order to make it as easy as possible for (new) book users to edit content and learn to use the JB2/MyST platform, we need a tool (button) that allows a user to authenticate with GitHub and "edits" to book source code (*.md and *.ipynb) are committed to a repo.

---

User story

User wants to contribute to a book repo. Perhaps they are participating in a training to learn about MyST; perhaps they are a teacher that only wants to edit the content on a single page for their course (e.g., fix an equation). It is not possible or not desired to install MyST on their computer. Luckily the user is able to fire up a browser-based text editor to contribute: Binder Hub hosted JupyterLab with the MyST extension (this will be described in another discussion/issue; ideally this would be possible on a Jupyter Hub, Binder Hub and even JupyterLite).

User accesses the editing environment by clicking on a URL in the source repo, or perhaps even from the book itself (ideally a "edit this page" button would fire up the JupyterLab instance and open the source file directly, ready for editing, but that may be out of scope for this tool).

After making edits to the source files, user is able to commit the change to the source repo. This would involve:

• dedicated button/dropdown menu for managing and executing github commits
• ability to select specific files to commit changes (no need to subdivide by line)
• authentication happens (i don't know how this works, but perhaps PAT or user credentials entered)
• confirms target repo (if github user has access, commit made to source repo; else commit goes to fork in users repo)
• repeat!
• GitHub authentication, uncommitted edits, etc, are lost when Binder is shut down.

Additional info

It seems like this would be a Jupyter Lab extension.

If this works on JupyterLab could it also work in JupyterLite?

The TeachBooks tool described in WYSIWYG #2404 includes such a button; that may give ideas for the UI.

Pitched during JupyterCon sprint. @fperez @JimMadge. Could also be used in @ryanlovett's JHub proxy. Will define a user story soon to connect these ideas.

[agoose77]

Tooling wise, I posited that we'd do this using an a renderer extension that we thought about -- with an .mjs renderer in the browser.

[rlanzafame]

I think this would only work for the case where editing the source is happening via the rendered book (website). So the WYSIWYG part would be needed.

If so, definitely a useful thing. But in the short term the only tool we have to get close to WYSIWYG (editing source and rendering outcome without book build) is the JupyterLab MyST extension.

[agoose77]

@rlanzafame yes, although my suggestion was that we would use that mjs mechanism to load in a full JupyterLite instance! So, the idea is to build the Jupyter tooling up to support that use case!

[rlanzafame]

🤯🤯🤯
Oh wow, awesome!

[JimMadge]

Some relevant thoughts in another discussion 🙏.

[rlanzafame]

@JimMadge here is an example of a JupyterLab extension for Git. See the gif at the top of the README: do you think this type of interaction would be OK for your users, or would it be better to have a more simplified set of buttons?

For our TeachBooks users definitely the simple buttons would be a "nice to have"

[JimMadge]

It looks good to me.

I think there is always a balance and if you over simplify you can end up obfuscating what is happening or reducing functionality. From a Turing Way perspective, I like that the plugin doesn't hide the features of git, like branches, tags, commit messages.