processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.13k stars 3.23k forks source link

[p5.js 2.0 RFC Proposal]: Publish original proposals through new proposal form #6813

Closed GregStanton closed 1 month ago

GregStanton commented 4 months ago

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)

  1. Increases accessibility of the p5.js 2.0 effort.
  2. Accelerates progress on a range of important proposals.
  3. Helps the community to determine which proposals to accept.
  4. Provides an easy way to record the decision-making process (the final RFC can link to the discussion for each proposal).
  5. Aids project management (accepted proposals can be organized via the p5.js 2.0 GitHub project).
  6. Facilitates upgrade guidance. [^1]
  7. Makes the final RFC easier to read by providing a common format for proposals. [^2]

[^1]: 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). [^2]: 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).

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

GregStanton commented 4 months ago

If anyone is interested in fleshing out one of the original proposals and submitting it through the new proposal form, please leave a comment! If anyone has questions about how this would work, please don't hesitate to ask here. To get things started, I'm inviting stewards from areas that seem relevant, along with a few others who I think may be interested.

Build and test system

@limzykenneth

Refactors

@mohitbalwani, @calebfoss, @cosmicbhejafry, @apoorva-a98, @tedkmburu, @Zarkv, @SkylerW99, @itsjoopark, @hannahvy, @nhasalajoshi

Modules

@jeffscottward, @davepagurek, @asukaminato0721, @lindapaiste

Libraries

Maybe contributors who've developed add-on libraries would be interested to help here? For now, I'll just list a few add-on library developers who seem to be active in the community.

@nickmcintyre, @quinton-ashley, @peilingjiang, @yining1023, @cvalenzuela, @bmoren, @davepagurek, @rev3rend, @two-ticks, @calebfoss, @stalgiag, @dhowe

Renderers

@davepagurek, @ChihYungChang, @teragramgius, @tuminzee, @Zarkv, @robin-haxx, @Gaurav-1306

Algorithm Changes

These are related to color and math.

@paulaxisabel, @SoundaryaKoutharapu, @mrbrack, @TJ723, @Zarkv, @SkylerW99, @ramya202000, @hannahvy, @robin-haxx, @hiddenenigma, @ericnlchen, @ChihYungChang, @bsubbaraman, @albertomancia, @JazerUCSB, @tedkmburu, @perminder-17, @Obi-Engine10, @jeanetteandrews

Reference

@asukaminato0721, @SoundaryaKoutharapu, @richardegil, @hannahvy, @bayomayo

Typography

@dhowe, @paulaxisabel, @SarveshLimaye, @SkylerW99, @BamaCharanChhandogi, @Obi-Engine10, @hannahvy, @singshris, @hiddenenigma

Misc

I know @nickmcintyre has provided feedback on some of this (e.g. p5.Table).

dhowe commented 4 months ago

@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...

limzykenneth commented 4 months ago

@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.

GregStanton commented 4 months ago

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.

[^1]: You may notice that some issues that carry the green "p5.js 2.0" label do not include "[p5.js 2.0 RFC Proposal]" in the title; that's because some proposals were submitted before the "p5.js 2.0 RFC Proposal" form was created.

limzykenneth commented 1 month ago

This has been completed