-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
To @Lee-W Regarding using branch name tracking documnets by year. I think that the current file structure, where historical documents are placed within different project folders, is not bad. |
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 belive a huge portion of the docs should be similar. Versioning can help deduplicate and have the following benefit
I'm good with placing these docs in different folder, but different repo might make it hard to find.
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 feel like this is one of the thing I'd like to prompt. but yep, your concern is valid. |
To @Lee-W
I'm not familiar with this type of tool but I'd like to play with them. 😎 Thanks to Wei Lee for your kindness 🙌
Thanks to Wei Lee for your illustration. I think the benefits are really attractive to me. It's worth a shot!
Might Wei Lee provide examples of scenarios where one repo needs to access documents in another repo?
I ideally want volunteers to benefit from this system.
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." |
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.
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.
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 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. |
To @Lee-W
Thanks to Wei Lee for giving me lots of suggestion and help. Let me study it 💪
Roger that.
I get it. It's really a difficult issue 🤔 Does Wei Lee have any idea to solve it?
What a cool idea! I think we can give it a try, even though the outcome may not be as successful as we hope. |
Branching is one of the way I'm thinking of. Or creating sub-directory might solve it as well.
Yep, but at least a start |
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 name2024
for this repo). This repo is awesome btw.The text was updated successfully, but these errors were encountered: