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

Fix hard-coded URLs #232

Open
8 tasks done
brianamarie opened this issue Jun 30, 2020 · 6 comments · May be fixed by #233
Open
8 tasks done

Fix hard-coded URLs #232

brianamarie opened this issue Jun 30, 2020 · 6 comments · May be fixed by #233
Assignees

Comments

@brianamarie
Copy link
Contributor

brianamarie commented Jun 30, 2020

(Thanks to @parkerbxyz for listing this in another issue! I'm moving to this new issue to be tracked separately)

As a part of open sourcing this repository, and renaming/moving it, one thing we’ll need to address is all of the hardcoded links to this repository that exist throughout its files:

My biggest concern is the teaching scripts. We’ll need to prepare a pull request with changes to the scripts that can be merged right after the rename to avoid disrupting any customer engagements. I think that goes for the remaining steps in the rename process; we’ll likely need to make the majority (if not all) of the changes in quick succession.

@parkerbxyz
Copy link
Contributor

@brianamarie what are your thoughts on using a custom (sub)domain for this repository? Instead of github.github.io/github-training-manual or github.github.com/github-training-manual, we could use the Professional Services subdomain so the URL would be services.github.com/github-training-manual. I think that would reduce redundancy in the URL (github.github.tld) and make the ownership of the site/repository more clear.

@brianamarie
Copy link
Contributor Author

@parkerbxyz I really like that idea.

Question about the "how": Is moving the URL to a subdomain something that we should include in this flow of change, or should we pursue it separately?

Everything at once

  • 👍 No double-phase of change that could lead to confusion
  • 👎 We would need to wait longer for open sourcing the repo, depending on how long the subdomain process takes

Separating into another workstream

  • 👍 We'd be able to open source the repo ASAP
  • 👎 We'd need another round of updates to the redirect (consequences of this may range from the inconvenience of a PR to confusing folks on where to find the repo)

@parkerbxyz @amyschoen what do you think?

@parkerbxyz
Copy link
Contributor

I’d personally like to do it all in one go if possible to avoid needing to handle multiple redirects.

@brianamarie
Copy link
Contributor Author

Sounds good to me, @parkerbxyz. Do you happen to know how we would begin to do this with http://github.com/github/services-site/?

@amyschoen
Copy link
Collaborator

I agree. One go is better even if it makes this take a tad longer.

@brianamarie
Copy link
Contributor Author

I've posed the question in the services-site repo, and mentioned the folks who show commit history from the site team: https://github.com/github/services-site/issues/222

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

Successfully merging a pull request may close this issue.

4 participants