You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To facilitate contributors efforts to create more and different forms of documentation (tutorials, explanations, demos, etc.) for different parts of the ecosystem, we should create a list of all the parts of Solid that could benefit from any documentation.
This might include every app, library, tool, and even existing documentation, such as protocols and specs, because: 1) even protocols and specs could benefit from things like: video explanations, examples of usage, simplification, clarification, etc., and 2) even things that are already well-documented could probably benefit from different types of documentation: videos, illustrations, etc.
This list, like other features on the site, should probably be tailored to serve two types of user: 1) those looking for documentation, and 2) those wishing to contribute. For the first type, they would be able to find a particular item on the list, and see what current documentation exists for that item. For the potential contributor, they would be able to browse the list and see what is missing from current documentation.
The first part of the work on this issue would probably be to figure out how to use the existing pod for onboarding resources to start creating this list. For example, let's say we want to add Soild-UI as a library that has some documentation, but could use more. Should we add it to our existing Links list, and maybe add a property to it, like relatedDocs, which would be an array of links to other documentation?
The alternative approach would be to create a separate list of all entities that could potentially benefit from further documentation . . . but this would probably overlap almost 100% with the Links list; therefore, the relatedDocs array (or similar) is probably the way to get started with this issue.
The text was updated successfully, but these errors were encountered:
YetAnotherJonWilson
changed the title
Create a list of apps, libraries and other Solid tools, with info on how much documentation exists for them
Create a list of existing apps, libraries and other Solid tools, with info on how much documentation exists for them
Nov 3, 2023
To facilitate contributors efforts to create more and different forms of documentation (tutorials, explanations, demos, etc.) for different parts of the ecosystem, we should create a list of all the parts of Solid that could benefit from any documentation.
This might include every app, library, tool, and even existing documentation, such as protocols and specs, because: 1) even protocols and specs could benefit from things like: video explanations, examples of usage, simplification, clarification, etc., and 2) even things that are already well-documented could probably benefit from different types of documentation: videos, illustrations, etc.
This list, like other features on the site, should probably be tailored to serve two types of user: 1) those looking for documentation, and 2) those wishing to contribute. For the first type, they would be able to find a particular item on the list, and see what current documentation exists for that item. For the potential contributor, they would be able to browse the list and see what is missing from current documentation.
The first part of the work on this issue would probably be to figure out how to use the existing pod for onboarding resources to start creating this list. For example, let's say we want to add Soild-UI as a library that has some documentation, but could use more. Should we add it to our existing
Links
list, and maybe add a property to it, likerelatedDocs
, which would be an array of links to other documentation?The alternative approach would be to create a separate list of all entities that could potentially benefit from further documentation . . . but this would probably overlap almost 100% with the
Links
list; therefore, therelatedDocs
array (or similar) is probably the way to get started with this issue.The text was updated successfully, but these errors were encountered: