-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Submitting and Archiving Proposals #128
Comments
+ 1 since, as you mentioned, dealing with that today was quite an awful experience in the issue I opened. |
Very much in favour of this +1 This matches with the concept of "Architecture Decision Records" that I've mentioned. |
Yes that's what I had in mind as well |
I submitted a template that we can use to quickstart a proposal: #129 |
Is there any work left here? Can this be closed since #129 was merged? |
I don't think so, we can close it. |
So far we've been using Google Doc for any non-trivial proposal regarding the Readium Toolkit, but it's not a great solution:
Using GitHub issues is not convenient either, because there's a single thread that becomes quickly difficult to follow. There's no easy way to update a proposal while notifying other contributors (as we can see in this recent issue from @JayPanoz).
I suggest following Apple's lead with the Swift Evolution repo and write proposals as Markdown document in GitHub. This has a number of advantages:
I've published a PR following this model, as a proof of concept.
If there're enough contributors interested in this approach, I'll draft a guideline to write the proposals.
The text was updated successfully, but these errors were encountered: