mirror of
https://github.com/mustbeperfect/definitive-opensource.git
synced 2026-04-25 18:25:40 +02:00
Changed header and main README now generated by script
This commit is contained in:
Lucas
8
.github/CONTRIBUTING.md
vendored
8
.github/CONTRIBUTING.md
vendored
@@ -13,16 +13,14 @@ Please note that this project is released with a [Contributor Code of Conduct](C
|
||||
The scale of what this project is attempting to accomplish is one that can only be done collectively. All contributions are highly valued. For submission guidelines on projects, please consult the [submission guidelines](guidelines.md)
|
||||
|
||||
>[!IMPORTANT]
|
||||
>When possible, please edit the file directly and start a pull request instead of raising an issue.
|
||||
>When possible, please edit the file directly and start a pull request instead of raising an issue. DO NOT EDIT THE README. Edit applications.json.
|
||||
|
||||
## Conventions
|
||||
To establish uniformity accross the project, please adhere to these conventions.
|
||||
- Use the project's official name, not the repository name. Repository names often use lowercase and place dashes in place of spaces. Fallback to **Title Casing** if capitalization is not clear.
|
||||
- Platform tags are listed in the following order: ```Desktop OS (Order: Windows, MacOS, Linux)```, ```Mobile (Order: Android, IOS)```, ```CLI```, ```SelfHost```, ```Web```, ```Plugin```
|
||||
- One space to the ```| left and right |``` for row elements
|
||||
- For projects with multiple repositories (EX: one for IOS, Windows, etc) link the organization. For API star retrieval use their most popular repository.
|
||||
- The description should be the repository description. If there are multiple repositories, no description, or an inadequate one, fall back to the organization or their official website, or the repo's README. **Do not write your own description and only use text from official sources of the project.** The ONLY change you can make is replacing ```|``` with ```-``` to prevent interference with our tables.
|
||||
- We use [Github Flavored Markdown (GFM)](https://docs.github.com/en/get-started/writing-on-github)
|
||||
- For projects with multiple repositories (EX: one for IOS, Windows, etc) link the repository with the most stars.
|
||||
- The description should be the repository description. If there are multiple repositories, no description, or an inadequate one, fall back to the organization, their official website, or the repo's README. **Do not write your own description and only use text from official sources of the project.** The ONLY change you can make is replacing ```|``` with ```-``` to prevent interference with GFM tables.
|
||||
|
||||
>[!NOTE]
|
||||
>These conventions can seem overly complicated. Make sure you skim over them but don't get too caught up over them. Basically, just follow what's already been done and fallback here when you aren't sure of something.
|
||||
|
||||
@@ -1068,14 +1068,10 @@ Projects that were once on this list but removed - usually due to abandonement o
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
|
||||
A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
|
||||
<summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
|
||||
A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
|
||||
<p> </p>
|
||||
However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
|
||||
<p> </p>
|
||||
The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system.
|
||||
<p> </p>
|
||||
As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind.
|
||||
The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex.
|
||||
</details>
|
||||
|
||||
## License
|
||||
|
||||
@@ -1090,14 +1090,10 @@ Projects that were once on this list but removed - usually due to abandonement o
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
|
||||
A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
|
||||
<summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
|
||||
A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
|
||||
<p> </p>
|
||||
However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
|
||||
<p> </p>
|
||||
The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system.
|
||||
<p> </p>
|
||||
As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind.
|
||||
The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex.
|
||||
</details>
|
||||
|
||||
## License
|
||||
|
||||
@@ -962,14 +962,10 @@ Projects that were once on this list but removed - usually due to abandonement o
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
|
||||
A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
|
||||
<summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
|
||||
A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
|
||||
<p> </p>
|
||||
However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
|
||||
<p> </p>
|
||||
The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system.
|
||||
<p> </p>
|
||||
As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind.
|
||||
The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex.
|
||||
</details>
|
||||
|
||||
## License
|
||||
|
||||
@@ -1063,14 +1063,10 @@ Projects that were once on this list but removed - usually due to abandonement o
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
|
||||
A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
|
||||
<summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
|
||||
A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
|
||||
<p> </p>
|
||||
However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
|
||||
<p> </p>
|
||||
The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system.
|
||||
<p> </p>
|
||||
As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind.
|
||||
The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex.
|
||||
</details>
|
||||
|
||||
## License
|
||||
|
||||
@@ -2,20 +2,19 @@
|
||||
> [!TIP]
|
||||
> Discussions and contributions are welcome! This project is in it's early stages and a lot hasn't been ironed out yet. For more information on [contributing](.github/CONTRIBUTING.md) and [guidelines](resources/dev/GUIDELINES.md) for open-source software submissions, consult their respective pages.
|
||||
|
||||
> [!CAUTION]
|
||||
> We are currently undergoing major changes and refactoring as we migrate to a JSON file with Python scripts that generate the READMEs.
|
||||
|
||||
> [!NOTE]
|
||||
> My MacOS [configuration](https://docs.google.com/document/d/1QF7wpvlFG7mfWtCGrFfyIUwgYzOYeSBDAIDvgiIJk44/edit?usp=sharing).
|
||||
|
||||
##
|
||||
|
||||
<h4 align="center">
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/resources/dev/GUIDELINES.md">Guidelines</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/windows.md">Windows</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/issues">Issues</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/macos.md">MacOS</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/.github/CONTRIBUTING.md">Contributing</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/linux.md">Linux</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/selfhost.md">SelfHosted</a>
|
||||
</h4>
|
||||
|
||||
##
|
||||
|
||||
@@ -44,7 +44,7 @@ def generate_readme_for_platform(platform):
|
||||
content += f.read() + "\n"
|
||||
|
||||
# Write output file
|
||||
output_filename = "source/testing/test.md" if platform == "all" else f"readmes/{platform}.md"
|
||||
output_filename = "README.md" if platform == "all" else f"readmes/{platform}.md"
|
||||
with open(output_filename, "w", encoding="utf-8") as f:
|
||||
f.write(content)
|
||||
print(f"Generated {output_filename}")
|
||||
|
||||
@@ -13,20 +13,19 @@
|
||||
> [!TIP]
|
||||
> Discussions and contributions are welcome! This project is in it's early stages and a lot hasn't been ironed out yet. For more information on [contributing](.github/CONTRIBUTING.md) and [guidelines](resources/dev/GUIDELINES.md) for open-source software submissions, consult their respective pages.
|
||||
|
||||
> [!CAUTION]
|
||||
> We are currently undergoing major changes and refactoring as we migrate to a JSON file with Python scripts that generate the READMEs.
|
||||
|
||||
> [!NOTE]
|
||||
> My MacOS [configuration](https://docs.google.com/document/d/1QF7wpvlFG7mfWtCGrFfyIUwgYzOYeSBDAIDvgiIJk44/edit?usp=sharing).
|
||||
|
||||
##
|
||||
|
||||
<h4 align="center">
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/resources/dev/GUIDELINES.md">Guidelines</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/windows.md">Windows</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/issues">Issues</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/macos.md">MacOS</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/.github/CONTRIBUTING.md">Contributing</a>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/linux.md">Linux</a>
|
||||
<span> · </span>
|
||||
<a href="https://github.com/mustbeperfect/definitive-opensource/blob/main/readmes/selfhost.md">SelfHosted</a>
|
||||
</h4>
|
||||
|
||||
##
|
||||
@@ -49,10 +48,11 @@ This list aims to serve as a single centralized location for the best of open so
|
||||
|
||||
Definitive-opensource was initially a single markdown file that was edited directly. However, as the list scaled, this manual approach proved cumbersome and limited. Additionally, as popularity increased, we recieved many requests for README's of individual platforms - something that would be not be realistic to do manually.
|
||||
<p> </p>
|
||||
As of v0.6.2-beta, the project was fundamentally re-made. Categories and applications were put in categories.json and applications.json, respectively. Python scripts were made to generate one main list and more platform-specific lists. This was paired with GitHub actions to run the scripts when any changes were made. This makes refactoring the list format far easier and eliminates typos. This new system also opens the door to
|
||||
As of v0.6.2-beta, the project was fundamentally re-made. Categories and applications were put in categories.json and applications.json, respectively. Python scripts were made to generate one main list and more platform-specific lists. This was paired with GitHub actions to run the scripts when any changes were made. This makes refactoring the list format far easier and eliminates typos.
|
||||
<p> </p>
|
||||
The project architecture is as follows:
|
||||
```text
|
||||
<p> </p>
|
||||
<code>
|
||||
definitive-opensource/
|
||||
├── assets/
|
||||
├── readmes/
|
||||
@@ -66,7 +66,7 @@ This list aims to serve as a single centralized location for the best of open so
|
||||
| └── utils/
|
||||
│ └── testing/
|
||||
└── README.md
|
||||
```
|
||||
</code>
|
||||
</details>
|
||||
|
||||
## Project Status
|
||||
@@ -1330,14 +1330,10 @@ Projects that were once on this list but removed - usually due to abandonement o
|
||||
|
||||
## FAQ
|
||||
<details>
|
||||
<summary><b>How about a JSON file with scripts or a website?</b></summary> <br />
|
||||
A JSON file with scripts that generate the README(s) would make fundamental changes and reorganization far easier whilst minimizing formatting and grammatical errors. A website would provide much requested features like tag based filtering and even automation.
|
||||
<summary><b>Will there ever be a definitive-opensource website?</b></summary> <br />
|
||||
A website is definitely on the roadmap. It would provide much requested features like tag based filtering and, on the backend, automate much of what we currently have to do manually. However, for the foreseeable future, the list will remain as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within. The complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file.
|
||||
<p> </p>
|
||||
However, for the foreseeable future, the list will to be edited directly as a markdown file for one reason: to keep things simple. The current system lets me focus solely on the projects within, not how to present said projects.
|
||||
<p> </p>
|
||||
The current markdown system could also be considered a stepping stone to guage the community's needs prior to building a more complex system. I will likely migrate to a JSON file as the project scales and when I have time to architect such a system.
|
||||
<p> </p>
|
||||
As for the website, the complexities of web development seem unnecessary and an added pain for a task that can suffice, for now, as a markdown file. Depending on the popularity of the project, however, this idea will remain in the back of my mind.
|
||||
The current system could also be considered a stepping stone to guage the community's needs prior to building a website, which would inherently be far more complex.
|
||||
</details>
|
||||
|
||||
## License
|
||||
|
||||
Reference in New Issue
Block a user