Instructions how to send a draft #2
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It would be nice to have clear instructions on the webpage how to participate. It currently says "Draft-based. Send a new draft whenever you have something people should read.". Whats a draft and where do I send it?
Absolutely. I wrote a "minimum viable" document at first since I wasn't sure if anyone would join yet :p
A draft is just like a SRFI draft. I.e. a git commit where the document and code are in a shape where you want people to take a(nother) look at it.
You can find git tags corresponding to each draft in every SRFI's repo. E.g. SRFI 207 has seven of them:
draft-1throughdraft-7. This has worked well.The HTML document of each draft is pushed to the SRFI website. Whenever you click on a SRFI there, the site takes you to the latest draft of that SRFI. This has also worked naturally. (People rarely need to revisit old drafts, but they can be retrieved from git if needed.)
In between the draft commits there are ordinary git commits as the author works on the SRFI. These are not announced to readers, and the HTML is not uploaded to the SRFI website, but especially interested readers can follow these using git.
IMHO all of the above has worked very well and we should copy it.
As for where to send te draft...
SRFI has one person who is the Editor (for the last few years it's been Arthur). Drafts are sent to him.
We don't have an editor planned; I hope the process can operate by consensus. Just make a new git repo by following the example of the existing ones and I'll regenerate the front page.
No worries. :) It will take me a while to have anything to present. I was just thinking from a position of a newcomer, which I am also in many ways. If we imagine someone lands on that web page and is interested it would be nice to have either the instructions or link to them on there. If the instructions are just here in the comments I dont think people will find them. I would have made a pull request to the website repo to save you the effort if I knew the "How To" myself.
I think since this process is more relaxed than SRFI it would make sense to make the participation process simple and guiding people is important for that.
Sure, take your time! It's going to be slow at first. If things go well, we'll start getting results (i.e. traffic and steadily improving proposals) in 6 months to a year.
The basic act that has to be done is to write a
document.mdto serve as the first draft. One of the regulars can then edit it so it conforms to the expected document structure, give it an ID number, and add it to the index.It doesn't really matter how the Markdown file arrives.
The submitter could make a repo under their own Gitea account, which the regulars will clone under gitea.scheme.org/review.
Or upload it to a web server and send the URL.
Or send it by email.
But currently a Gitea account is required to comment on proposals, so the simplest way is probably that the submitter makes a repo which is cloned.
How about these instructions, copied from srfi-discuss:
I would take out the last lines "(Just like in GitHub)" but otherwise it looks good.