Added first draft of E&T Working Group page

[JeffCarver]

Description

Motivation and Context

Checklist:

• I have posted the link for the PR in the usrse slack (#website) to ask for reviewers
• I have previewed changes locally
• I have updated the README.md if necessary

cc @usrse-maintainers

[JeffCarver]

Preview:

• New page: https://1635-120906408-gh.circle-artifacts.com/0/usrse.github.io/working_groups/education_training/index.html
• Modification to Working Groups page: https://1635-120906408-gh.circle-artifacts.com/0/usrse.github.io/about/working-groups/index.html
• Removed Skill Set from the Training Page: https://1635-120906408-gh.circle-artifacts.com/0/usrse.github.io/resources/training/index.html

Open Question, do we remove the Training page from the Resources tab or leave it there so it can be accessed multiple ways. For now, I have left it there.

[vsoch]

@JeffCarver good question - I think we should ask the rest of the group, maybe in slack? My 0.02 is that if our training materials aren't easy to find via the working groups page, there should be a link maintained there in the navigation, but it should then go to a page under the working groups. If the training is easy to find via the working group (and people would know to go there) then we don't need the navigation link. But methinks the second is probably not the case. Anyoo, either way we will want to have a consolidated set of pages for E&T! Take a look at the different groups of pages (e.g., about) to see how that works - basically you add a menu under _data/menus/ and then add it to the page front end matter and they will render together. And for human logic it then makes sense to keep them under pages/ in the same subfolder. Perhaps we should have like:

pages/
    working-group/
        education-training/
            # pages go here

and that is matched with a data file for it:

_data
    menus
        working-group-education-training.yaml

and other working groups can follow suit!

[vsoch]

Oh and one more note - for any pages that are replaced (e.g., if right now we have https://us-rse.org/resources/training/ and we want that to be under the education and training working group, maybe like https://us-rse.org/education-training/<name> the way we can do that to preserve links is added a redirect page under pages/redirects. it's fairly straight forward - in the frontend matter you define the permalink and the redirect URL.

[cosden]

I would vote to leave the training materials as a nav bar link. I think it's ok to have multiple ways to get there. And honestly, I just don't see someone not familiar with our internal structure of working groups finding their way to the WG pages naturally.

@vsoch - For right now I don't think we need a consolidated set of E&T pages, there just isn't enough. But, I expect/hope we will eventually, so doing it now makes sense. As you said others can follow suit. This is the kind of input and guidance that I think the WebDev group will need to give the other WGs (and anyone making content). How do we do this appropriately? I know there is overlap with us in this case, but pretend there isn't. Should WebDev (a) instruct in a PR, like you did and ask the WG to make the changes, (b) make the changes within the PR after the WG gives an ok, or (c) merge the content PR and then open a new one to restructure and then just ask the WG to approve?

[JeffCarver]

@cosden I think option (c) makes the most sense. Let's go ahead and get this content posted (once other people in the E&T group have a chance to review). Then, the website team can determine how they want working group spaces to be structured for all groups. I think that decision lies with the website group not with the E&T group. I am going to go ahead and post the draft PR to the E&T Slack channel to get a few more eyes on the content of the new page. Then I'll turn it into a pull request.

[vsoch]

This is the kind of input and guidance that I think the WebDev group will need to give the other WGs (and anyone making content).

Agree!

How do we do this appropriately?

Well, that's why I'm here having this discussion with you! Right now there are two page layouts. A single page (e.g., the current training) and then grouped pages (e.g., About, or really any of the top level navigation groups that have a submenu.) If you have one page of content, use the first. If you have more than one, use the second. If you don't like either of these options and want something different, then that would make sense to express this to the webdev group (and even in a thread here is fine and we can link in slack) and we can develop this for you. Regardless of the layout you choose, we likely need to have a discussion about how to generally link to these more detailed pages. Right now I'd say to just have a link on the working groups page to extra content pages, and create the new page structure under pages/ and _data/menus/ as I mentioned before.

I know there is overlap with us in this case, but pretend there isn't. Should WebDev (a) instruct in a PR, like you did and ask the WG to make the changes, (b) make the changes within the PR after the WG gives an ok, or (c) merge the content PR and then open a new one to restructure and then just ask the WG to approve?

I think the issue is timing - webdev isn't going to meet until next year, so if you rely on that you will be waiting a long time! If you want to wait, I'd say go for A - the suggestions I made can be brought to the group for discussion first, but add some detail about your needs. I think an intermediate would be to post my proposal in the slack to get an A-OK before you make changes in the PR - that might be the best alternative to waiting months. I wouldn't go for C - merging content and then having to re-do it (and preserve links that are changed) is not needed and good if we can avoid it.

Let me know if you'd like me to start this engagement in the webdev channel and I'll make an original post, and then you can comment with details I missed. Thanks for spear-heading (being the first wg) to work on this!

[cosden]

@vsoch - let's discuss the general case in slack (#website) rather than here. I don't think we need a webdev meeting. If you're up for starting it, that would be great. I think we want to make things as easy as possible for the content developers without putting the web developers in technical debt.

@JeffCarver - unfortunately this looks like it's stressing the system - in a good way. Is it ok we take a bit to figure out the right way to get this through? Is there a day you wanted/needed this to go live (next E&T meeting, AGM, etc)?

[JeffCarver]

@cosden the plan sounds good. I'd like to be able to announce it at the AGM. So, if we could be ready to merge something the week after Thanksgiving, that would be great.

[vsoch]

@cosden that works for me.

[JeffCarver]

I have received feedback from some of the E&T group that the new page looks good. We will leave the current link in place for now. I have changed this to a pull request. I would like to have this merged in time to announce at the AGM on Friday.

[vsoch]

okay so let's have some quick discussion! @cosden I think we should have the working groups url just be /wg/ instead of working group, or /w-g/. Or we could shorten to /groups/. This would be the namespace for all working group specific pages. Thoughts?

[mtbc]

/wg/ sounds good to me.

[cosden]

I'm good with /wg/ too. Following up on the slack conversation, I think it makes sense to have a sub folder for each wg as they expand to want to generate more content associated with the group. There may be content (as is in this case) that goes outside of the /wg/ directory, and I think that's fine. So for this PR, I'm good with it as is after the change to /wg/.

And I think it's fine to move forward with the plan now, and if we need to come back and adjust after other WGs make pages, that's ok.

[vsoch]

Agree!

[JeffCarver]

I made the change to the directory name. I think the PR is ready to be merged now.

[vsoch]

Thanks @JeffCarver ! Taking a look for a final review now.

[vsoch]

I'm in agreement - looks good.