Prepare to publish first draft. ReSpec tooling and sample content #20
Conversation
Signed-off-by: Hadrian Zbarcea <[email protected]>
|
I need to fight formatting a bit more, to make it more compact. |
| * Technical: related to infrastructure tasks (e.g., "As a Service Provider, I want the ability to archive LWS storages"). | ||
| Spike: used to explore or research an unknown aspect of the project (e.g., "Research what Identity System supports delegation."). | ||
|
|
||
| ## How to build this spec |
There was a problem hiding this comment.
I suggest to simplify this section; most people (that is, everyone except editors, really) won't need to run respec manually, they will simply let the browser do the rendering.
What they need to do is
- run a local http server (with
npmas documented below, or withpython3 -m http.serverwithout anything to install) - then visit
http://localhost:8080/spec/index.html
Let's not make the README overly intimidating :)
There was a problem hiding this comment.
Point taken. I thought about it as well, and the question indeed, is what the purpose of the README is. I will not make a change yet, but immediately after merging this PR I will split a BUILD.md out of the README and put the respec related pieces there. We still need to clarify what the audience for the README is and what content fits there @pchampin. Thanks!
| copyrightStart: "2024", | ||
| // previousPublishDate: "N/A", | ||
| editors: [ | ||
| { name: "Pierre-Antoine Champin" }, |
There was a problem hiding this comment.
I'm happy to help as staff contact, but I'd rather not commit to take editor's responsibilities, at least for in the short term.
There was a problem hiding this comment.
@pchampin agree, but you created the skeleton and your name was there. Please feel free to add a PR to remove or, better, leave it there knowing the limitation of responsibilities you made clear.
There was a problem hiding this comment.
Seems to me, @pchampin qualifies for author, as skeleton creator. This does not imply any future responsibilities.
|
@hzbarcea please also note that, as an editor, you should be able to push a branch directly on this repo, and make a PR from there. You do not need to work from a fork of this repo. |
Co-authored-by: Aaron Coburn <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Co-authored-by: Pierre-Antoine Champin <[email protected]>
Of course I am aware of this. It's easier for me to manage branches on a fork and keep the spec repo clean (and small) as much as possible. We can have branches on the spec to explore alternatives, but as far as working branches go, they belong more on forks, in my experience and habits. Not a biggie either way, you're obviously right. |
Co-authored-by: Pierre-Antoine Champin <[email protected]>
No description provided.