nonspec: Create dedicated current activities page #1268
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
marcelamelara
changed the title
marcelamelara
force-pushed
the
coming-up
branch
from
64ea56c to
b64c191
Compare
|
Actually, something is still off about how the new page is being formatted. If anyone has any ideas for what I'm missing, please let me know. |
Just guessing..., the other examples I see (e.g. https://github.com/slsa-framework/slsa/blob/main/docs/spec/draft/whats-new.md?plain=1) don't specify |
I'll give this a try. FWIW, I copied the top matter from the community page, which does seem to use "standard" layout. |
marcelamelara
force-pushed
the
coming-up
branch
from
542d4a6 to
c1e8563
Compare
There was a problem hiding this comment.
LGTM. Thanks for doing this.
I noticed that on the front page (index.md) we have a section titled 'Project status' but it is all the way at the bottom of a really long page. I think it would be worth updating that section to add a link to this new page and move that section much higher up onto the page. But this could be done in a different PR focused on refreshing the home page which could use a bit of scrubbing (like the list of companies listed is seriously out of date).
So this means we have the same text copied in two different places, because the exact same "Project status" section was (before I edited it) on the Community page. I vote to only keep one version of 'Project Status' so we don't have to remember to sync these two pages. Having this blurb on index.md makes more sense to me.
In general, I think we'll need several PRs to update several pages. The Community page is also seriously out of date, for example. What I can do in this PR is move the updated 'Project Status' out of the Community page into index.md, and a future PR can handle restructuring/other updates of the landing page. |
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Co-authored-by: Tom Hennen <[email protected]> Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
force-pushed
the
coming-up
branch
from
378f179 to
2780c39
Compare
Signed-off-by: Marcela Melara <[email protected]>
Yes, I fully agree. We should avoid duplication at all cost.
Sounds good. |
Signed-off-by: Marcela Melara <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: Marcela Melara <[email protected]>
| The goal of a Build Environment track is to enable the detection of tampering | ||
| with core components of the compute environment executing builds. |
There was a problem hiding this comment.
Are we introducing terminology here? Should we just say the build platform?
There was a problem hiding this comment.
What terms are you concerned about specifically?
There was a problem hiding this comment.
Given #1275, I'm going to defer any potential changes here to a later PR.
| These requirements are **subject to significant change** while this track | ||
| is in draft. |
There was a problem hiding this comment.
Are you trying to highlight that the build environment track has had less iteration/refinement than the source track? This feels like it should be a general call-out instead of a specific one.
There was a problem hiding this comment.
Not specifically, the intent here was simply to emphasize that the BuildEnv track is still in draft, irrespective of the status of the source track. I don't mind removing this line if you think it's redundant.
Here is my first take on the new navigation approach. This PR doesn't make any changes to how the specification is organized with regard to the tracks, etc. It is meant to be merely a UI modification, essentially changing the navigation bar so that the various versions of the specification are directly visible and accessible rather than dependent on using the version selector which only appears once you go into the specification. I didn't include the older versions: 0.1 and 1.0-rc1 and rc2. All of these are however still there and can be accessed directly via their respective URLs or from any page linking to them such as past blog posts. Let me know if you think we should add 0.1 to the navigation bar. I'm also not sure there is value in having the 1.1 RC given that I think it's a dead-end (if anything I think this should be 1.0.1). In the process of making this change I found a few bugs that I was able to fix. Any feedback or suggestions welcome but please keep in mind that Jekyll is a **static** page generator so anything that requires dynamic processing (either server-side or client-side) is out of scope. These would require PHP and/or Javascript. I've more or less managed to get my head around Jekyll and its template programming language Liquid but I'm not up for the added complexity any of this would imply. PR #1268 will have a small impact that I'll handle once it is merged. --------- Signed-off-by: Arnaud J Le Hors <[email protected]>
Following our ongoing discussions about questions of SLSA's current status, I quickly put together a new page for the website that outlines our current activities. This is mostly meant to be a starting point that we can improve upon as we figure out the best way to communicate our ongoing activities.