Here are the things to update/address in publishing the gh-pages Aries RFCs website. This is a checklist that we can both checkoff things as they are completed, and cross off (strike through) things that the community decides is not a good idea and should not be done.
[ ] Update the repository README to direct those arriving on the site to the published site.
[ ] Add a new landing page for the published site that gives guidance to those arriving how to use/navigate the site. Ideally, make the guidance tailored to each audience.
[ ] Add a document about Aries Interop Profiles.
[ ] Rename the current GitHub repository README document to "Lifecycle" and in the published site, move it to the governance section.
[ ] Add an "implementations" document that is in the "Welcome" section, in which implementations (frameworks, apps built on frameworks, etc.) are listed. Add initial section for ACA-Py, Aries VCX, Credo, Bifold Wallet, VC-Authn, etc.
[ ] Create a document per status -- content pulled from the "Lifecycle" document -- make them the landing page document in the corresponding status section of the published site, and update the links in the RFCs to point to the status document instead of the lifecycle document.
[x] Clean up the mkdocs errors around missing absolute and relative links. Fixing them will be a combination of fixes in the source documents (especially for the mailtos), and on the fly updates to the copies of the markdown files that are published (see the code/genSite.sh script for examples of such fixes. Experience shows that it is not always possible to have a link that works in both the GitHub UI and on a published mkdocs site.
[x] Change the status of proposed RFCs that have been implemented to either implemented or accepted, as appropriate.
[ ] Reverse the listing order of "Proposed" RFCs, as their relevance varies by age. The older they are the (generally) less relevant the are.
[ ] Add a document at the top of the "AIP 2.0" section that describes AIP 2.0 -- pulled from Aries RFC 0302.
[ ] Add a section with just a single document (for now) called "AIP 3.0" that talks about the goals for AIP 3.2 and a preliminary list of RFCs to be include (and created).
[ ] Add a "DIDComm V2.0" section and copy in all of the DIDComm v2 RFCs into the section. This would/could turn this site into the "didcomm.org" site.
[ ] Document the /code folder and how to use the tools. Add it to the governance section.
Comments welcome on this issue on these items or additional features to be added.
Here are the things to update/address in publishing the gh-pages Aries RFCs website. This is a checklist that we can both checkoff things as they are completed, and cross off (strike through) things that the community decides is not a good idea and should not be done.
mailtos), and on the fly updates to the copies of the markdown files that are published (see thecode/genSite.shscript for examples of such fixes. Experience shows that it is not always possible to have a link that works in both the GitHub UI and on a published mkdocs site.proposedRFCs that have been implemented to eitherimplementedoraccepted, as appropriate.Reverse the listing order of "Proposed" RFCs, as their relevance varies by age. The older they are the (generally) less relevant the are./codefolder and how to use the tools. Add it to the governance section.Comments welcome on this issue on these items or additional features to be added.