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

[All] Should we use static site generating tool to make a a static site? #107

Open
Lee-W opened this issue Apr 20, 2024 · 6 comments
Open

Comments

@Lee-W
Copy link
Member

Lee-W commented Apr 20, 2024

What problem does this task solve?

Make this repo easier to read.

What does the proposed task look like?

We'll need to introduce tools like mkdocs to generate the page. I can help with it if it's something we want.

Reference

I am not sure whether it makes sense, but should we change the repo to pycontw-program-brochure and use branch name track documents by year (e.g., we can use branch name 2024 for this repo). This repo is awesome btw.

@Xiao75896453
Copy link
Collaborator

To @Lee-W
Thaks Wei Lee
It's wonderful ! I also want to write a README. I could assist you to do this issue togather 🤗

Regarding using branch name tracking documnets by year.
What goals and benefits does Wei Lee want to achieve?

I think that the current file structure, where historical documents are placed within different project folders, is not bad.
Additionally, using branches may potentially increase the complexity, leading to a decrease in volunteers' willingness to use this repo 😥 (as we cannot guarantee that all volunteers are familiar with Git).

@Lee-W
Copy link
Member Author

Lee-W commented Apr 25, 2024

It's wonderful ! I also want to write a README. I could assist you to do this issue togather 🤗

Are you familiar with this kind of tools? If you want to play with them, I can work with you to get you familiar with them if you wish to 🙂 Otherwise, it's pretty easy for me to set up myself.

What goals and benefits does Wei Lee want to achieve?

I belive a huge portion of the docs should be similar. Versioning can help deduplicate and have the following benefit

  1. smaller repo size
  2. do not need to start from fresh. e.g., when we start 2025, we can just checkout branch 2025 from 2024 and set 2025 as default branch.

I think that the current file structure, where historical documents are placed within different project folders,

I'm good with placing these docs in different folder, but different repo might make it hard to find.

using branches may potentially increase the complexity, leading to a decrease in volunteers' willingness to use this repo 😥

Yep, possibly 🤔 In my original assumption, as long as the leaders have some basic knowledge, it should be fine. Others would use it as it is now. But I'm might be biased on this

(as we cannot guarantee that all volunteers are familiar with Git).

I feel like this is one of the thing I'd like to prompt. but yep, your concern is valid.

@Xiao75896453
Copy link
Collaborator

To @Lee-W

Are you familiar with this kind of tools? If you want to play with them, I can work with you to get you familiar with them if you wish to 🙂 Otherwise, it's pretty easy for me to set up myself.

I'm not familiar with this type of tool but I'd like to play with them. 😎 Thanks to Wei Lee for your kindness 🙌

I belive a huge portion of the docs should be similar. Versioning can help deduplicate and have the following benefit

Thanks to Wei Lee for your illustration. I think the benefits are really attractive to me. It's worth a shot!

I'm good with placing these docs in different folder, but different repo might make it hard to find.

Might Wei Lee provide examples of scenarios where one repo needs to access documents in another repo?

Yep, possibly 🤔 In my original assumption, as long as the leaders have some basic knowledge, it should be fine. Others would use it as it is now. But I'm might be biased on this

I ideally want volunteers to benefit from this system.
When planning a project, you can quickly find all relevant historical documents.

I feel like this is one of the thing I'd like to prompt. but yep, your concern is valid.

I think what @chihsuan said is quite insightful "There might be more benefits to using Google Drive instead of GitHub for storing documents, because Google Drive is more user-friendly."
We can try to make PyCon GitHub as user-friendly and convenient as possible.

@Lee-W
Copy link
Member Author

Lee-W commented Apr 29, 2024

I'm not familiar with this type of tool but I'd like to play with them. 😎 Thanks to Wei Lee for your kindness 🙌

Great. Here are a few suggestions or steps we could achieve this. You can decide when you want me to help or even take over (if you're no longer interested in or have no time on this). Just let me know.

  1. Decide which tool we're going to use to build the site. e.g., mkdocs, pelican, spinx (with myst)
  2. Setup the github actions so that we can have the pages built whenever we update the docs

Might Wei Lee provide examples of scenarios where one repo needs to access documents in another repo?

Oh, it's not what I intented to do. What I meant is finding the repo itself. and we'll end up with lots and lots of repos in this organization.

I ideally want volunteers to benefit from this system.

ah yes, that's definitly what we want. What I meant was letting the leader to change the git config stuff and rest of the step should be the same as it is now. Well... ideally

I think what @chihsuan said is quite insightful "There might be more benefits to using Google Drive instead of GitHub for storing documents, because Google Drive is more user-friendly."
We can try to make PyCon GitHub as user-friendly and convenient as possible.

I completely agree that Google Docs is often the better option, but I also think it would be great if more people could have the chance to try out Python or Git. This is something I personally hope to achieve at PyCon TW (although it may not be the goal of the entire community lol). As you mentioned, making these tools more accessible is crucial to accomplishing this.

@Xiao75896453
Copy link
Collaborator

To @Lee-W

Great. Here are a few suggestions or steps we could achieve this.

Thanks to Wei Lee for giving me lots of suggestion and help. Let me study it 💪

You can decide when you want me to help or even take over (if you're no longer interested in or have no time on this). Just let me know.

Roger that.

Oh, it's not what I intented to do. What I meant is finding the repo itself. and we'll end up with lots and lots of repos in this organization.

I get it. It's really a difficult issue 🤔 Does Wei Lee have any idea to solve it?

This is something I personally hope to achieve at PyCon TW (although it may not be the goal of the entire community lol).

What a cool idea! I think we can give it a try, even though the outcome may not be as successful as we hope.

@Lee-W
Copy link
Member Author

Lee-W commented Jun 15, 2024

I get it. It's really a difficult issue 🤔 Does Wei Lee have any idea to solve it?

Branching is one of the way I'm thinking of. Or creating sub-directory might solve it as well.

What a cool idea! I think we can give it a try, even though the outcome may not be as successful as we hope.

Yep, but at least a start

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

2 participants