-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[p5.js 2.0 RFC Proposal]: Publish original proposals through new proposal form #6813
Comments
@GregStanton how does one comment on the document above, or is the idea to move these into separate RFCs? And if so, where is the list of current RFCs under discussion ? It feels like there is a ton of good work in progress for v2.0, but coming back after a couple of weeks, I'm confused about which documents/issues are live/current and where to focus my attention... |
@dhowe The idea is to create RFC issues for them as they currently lives in the full RFC document I put together. It is a bit tricky to manage at this point and we don't have the capacity to organize very much at this point, I eventually will use the GitHub project tracker to keep track of all proposals and it will serve as the single source of truth for RFC statuses. |
Hi @dhowe! Thanks so much for your questions. Answering them will help clarify the process for everyone, so I'll add a few points to the explanation from @limzykenneth. If anything is still unclear, please let me know! "Is the idea to move these into separate RFCs?"Yes. The goal of this proposal (#6813) is to use the "p5.js 2.0 RFC Proposal" form to create separate GitHub issues from each of the proposals in the Markdown version of the RFC. "How does one comment on the document above..."Moving the proposals from a Markdown document to separate GitHub issues will make it possible for community members to add comments. It will also make all proposals accessible from one place. "Where is the list of current RFCs under discussion?"Recent proposals can be accessed by performing a search for issues with the "p5.js 2.0" label.1 The original set of proposals in the Markdown document will not appear in the search results until we convert them to GitHub issues. "I'm confused about which documents/issues are live/current..."As I write this, the lists provided in issue #6678, in the GitHub project for p5.js 2.0, and in the Markdown version of the RFC are all outdated. Using the "p5.js 2.0" issue label, as described above, is your best bet for an updated list of live issues. "And where to focus my attention..."If you want to help with the current issue (#6813) by converting a Markdown proposal to a GitHub issue, that'd be a big help. More generally, you can check the body of issue #6678 for an overview of the effort toward p5.js 2.0; just remember that the list of issues provided there is outdated. Footnotes
|
This has been completed |
Increasing access
This change would enable the community to provide feedback on the original RFC proposals. It would also give them the opportunity to express their interest in helping with implementations.
Which types of changes would be made?
Most appropriate sub-area of p5.js?
What's the problem?
In Issue #6678, an emphasis has been placed on the importance of community feedback; however, in nine of the ten original proposal categories, there is no viable way for the community to provide this feedback. Those nine categories are listed below:
Specifically, it was observed early on that the discussion in that issue is too hard to navigate. Since then, the discussion has only become harder to navigate.
What's the solution?
Since the RFC was originally released, we've developed a new proposal form dedicated specifically to gathering feedback on proposals for p5.js 2.0. We've already begun inviting more of the community to participate, including through a banner announcement on the Processing Discourse. All that's left is to publish the original RFC proposals with the new form.
In the one case (out of ten) where an original proposal was submitted through the form, as Issue #6767, the community immediately helped to flesh it out and rapidly iterated on the original idea.
Pros (updated based on community comments)
Cons (updated based on community comments)
Publishing the original proposals through the proposal form requires time, since in some cases key information such as accessibility statements may be missing. However, adding that information is arguably necessary, so this doesn't seem like an additional cost.
Proposal status
Under review
Footnotes
This idea is based on a comment from @kjhollen. For example, proposal authors might be asked to write "user-impact summaries," which would describe how the changes will directly affect users. These summaries could then be used to develop user-friendly guidance on how to manage the upgrade (e.g. as blog posts or videos, similar to when the p5.js Web Editor was rolled out). ↩
For each proposal submitted through the issue form, the access statement, problem statement, and solution statement can be copied into the RFC, along with a link to the issue for anyone who wants to see the full discussion. Proposals that are accepted for p5.js 2.0 can go into one category, and proposals that aren't accepted can go into another (it will be useful to have a record to indicate why proposals weren't accepted, and in some cases, proposals that aren't accepted for p5.js 2.0 may still be implemented after its release). ↩
The text was updated successfully, but these errors were encountered: