Document our authenticated static website hosting service

[choldgraf]

Context

@yuvipanda is wrapping up adding the ability to host authenticated static websites via the JupyterHub. For example, we could point the hub to a GitHub repository and have it serve the contents of a branch (assuming they're all HTML) as a website.

We have a little bit of documentation at the link below, but we could probably make that a dedicated section, and put other stuff underneath it:

• https://docs.2i2c.org/en/latest/admin/howto/content.html#serve-static-web-content-with-your-hub

Proposal

We should document this in our user-facing documentation so that others can discover how to use it, and when they might want to use it. Here are a few things that come to mind:

• How to enable the feature in the first place
• How to use this feature with private repositories
• What this feature is useful for, and when to use it
• Recommendations for how to build the HTML in the first place (e.g., GitHub Actions)

Updates and actions

• Add administrator documentation about this feature
• Remove any reference of docs-service from the user facing docs in this repo too https://github.com/2i2c-org/docs/blob/main/admin/howto/content.md#serve-static-web-content-with-your-hub

[choldgraf]

@jmunroe I'm adding you on this one in case you'd like to give it a whirl and work on documentation with me, and maybe we can use this as an opportunity to step through the documentation setup together. What do you think?

@yuvipanda I think we'll need your help in knowing how to actually trigger this, so we might ping you w/ questions!

also cc @arokem because his use-case is driving this functionality right now and it would be useful to hear what he likes / would want differently.

[yuvipanda]

@choldgraf i added a 'howto' doc in 2i2c-org/infrastructure#1502 on how to enable this, and I am going to write a 'topic' doc on how it works as well before i count that PR as ready to merge.

[yuvipanda]

I've worked today on supporting pulling from private git repos, and added docs for that too. I think that's good to go now. I'll add the topic document after scipy.

[GeorgianaElena]

We should also remove any reference of docs-service from the user facing docs in this repo too https://github.com/2i2c-org/docs/blob/main/admin/howto/content.md#serve-static-web-content-with-your-hub

[choldgraf]

James is going to give this a shot

Just had a meeting with @jmunroe about this and we agreed there was some confusion about who was responsible for this because so many people were assigned to the issue. We've unassigned @yuvipanda and @choldgraf so James can take the point on this one.

[damianavila]

Even when I understand how having a lot of assignees might be confusing... the idea of having multiple assignees goes in sync with the idea of working in teams on assigned issues. Maybe 3 was too much here, but this one would definitely need @yuvipanda's input and someone else writing that information, which I presume will be @jmunroe.

[choldgraf]

@damianavila I see the point of this as well - my question is "what is the action that being 'assigned' on an issue should evoke?".

In my opinion, the most important thing we can convey is "who is responsible for making sure this issue gets resolved". If we know the answer to that person, and they are empowered to ask for help from others, then I think that this is the best path to ensuring we get the issue done.

If we have multiple people assigned on the issue, and it is not clear which one of them needs to be pushing it forward, then it is more likely to be lost in the noise (like this one was) because nobody feels like they are the ones that must figure out a path forward and make progress.

Maybe we should discuss this in another issue / thread? It seems an important one to align on.

[yuvipanda]

In my opinion, the most important thing we can convey is "who is responsible for making sure this issue gets resolved". If we know the answer to that person, and they are empowered to ask for help from others, then I think that this is the best path to ensuring we get the issue done.

+1

[damianavila]

Maybe we should discuss this in another issue / thread? It seems an important one to align on.

Yep, I think the current assignment capabilities on GitHub do not have the proper granularity.
When you ask: "who is responsible for making sure this issue gets resolved"? I would say the paired team! (and this is why I was assigning multiple people to issues).
Then it is a matter to be more granular and define who, from that team, would be the lead and who the accompanying members. But I think it is important to align on the responsibility being carried by the team of two/three instead of the lead person who, in addition to the common goal, has the responsibility to be active in pushing forward the task.