Skip to content
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 #6678

Open
limzykenneth opened this issue Dec 30, 2023 · 86 comments
Open

p5.js 2.0 RFC #6678

limzykenneth opened this issue Dec 30, 2023 · 86 comments

Comments

@limzykenneth
Copy link
Member

limzykenneth commented Dec 30, 2023

Topic

It has been hinted a few times here and there but the RFC (Request for Comment) document for p5.js 2.0 is now ready!

What is p5.js 2.0?

p5.js 2.0 is the next major release of p5.js. A major release allows us more flexibility to make changes, and we need your help to make the most of it! We're inviting proposals now, and we're focusing all our effort on them (aside from bug fixes). For more context, see this working document, which will eventually contain all accepted proposals.

Access

To guide continued discussion a bit, we want to emphasize that RFC proposals must thoroughly and seriously consider increasing access especially, to quote from the p5.js access statement, "prioritize the needs of historically marginalized groups over the continued comfort of more privileged groups".

We want to take this quite seriously so that we don't venture down routes that goes counter to the goals of p5.js, and to re-emphasize that p5.js 2.0 does not change the goals, commitments, priorities, or non-priorities for p5.js as a project.

What kinds of changes will be accepted for p5.js 2.0?

Essentially, any change to an existing feature can be considered, provided it's difficult to make outside of a major release. For example, changing the name of a function is not hard to do, but we can only do it during a major release because we need to notify users well in advance. That being said, we aim to keep as much backwards compatibility as reasonable for p5.js 2.0 and breaking changes will need a good reason to be so.

How can individuals submit a proposal for p5.js 2.0?

Fill out the p5.js 2.0 proposal form! Anyone can do this.

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

Proposed timeline for the p5.js 2.0 (TBD)

  • February/March: Establishing access goals and defining values for p5.js 2.0
  • February/March/April/May: Accepting and reviewing proposals for p5.js 2.0, with a focus on access (like accessibility and FES)
  • April 11-13: Hosting an in-person meeting to discuss p5.js 2.0 proposals during OSACC
  • May/June: Wrapping up proposal review process
  • July-End of 2024: Actively implementing the selected features for p5.js 2.0

For those not familiar with the term RFC, it essentially means it is a proposal (often with a formal structure) that is inviting comments and discussion from the wider community on. The p5.js 2.0 RFC is not as formal as other RFC, I'm merely using it as a base structure to begin discussions so don't feel restricted in anyway and I want to gather as much feedback as possible on it.

The document is accessible here which also lives in a working branch of p5.js 2.0. I'm keeping the RFC document in git mainly because I want to keep track of changes to it, which at the same time also means it is at this stage a living document while we have discussions around what p5.js 2.0 can be like.

Each of the major differences/features p5.js 2.0 will have over the current 1.x version is split up into individual proposals in the RFC. I won't go into too much detail about the RFC here otherwise I will just be repeating what's already written in the RFC. Some proof of concept implementations are also present in the branch.

Anyone is welcomed to leave comments on any of the proposals of the RFC here and I particularly like to invite @Qianqianye @davepagurek @nickmcintyre @GregStanton who are either core contributors or have recent significant contributions, to have a look at the RFC. If there is anyone else you think may be interested in leaving comments on any of the proposals, you may wish to tag them as well. I may arrange for larger community video calls to go through things in general or in details as well, more info will come later.

@JustZambetti
Copy link

Color Module

The user should be able to

  • use different color spaces;
  • import new color spaces using addons.

We need a consistent Color API to communicate with many renderers, which make it unfiesable to have renderer dependent color spaces (ex: if you want to use the 2D renderer you have to use HSL). Therefore we could convert any color space to a big-enough one (like ProPhoto RGB) and use that in every renderer.

Proposal

I would use an abstract ColorSpace class with abstract methods to get the common color space. Every color space addon only have to extend the class.

About the public API, a solution could be to remove the ColorMode() functionality and just use functions.

fill(rgb(0,255,0));
fill(hex("00ff00"));

What do you think?

@limzykenneth
Copy link
Member Author

@JustZambetti I'm not sure it is possible to have a common color space that represents every color. First there might not be a color space that encompass every possible color; but secondly and more importantly, the use of a color space is more about describing the relationship between one color and another, ie. as the name implies it puts colors in dimensional space so it would be possible to navigate from one to another.

The approach I would like to go with for this is closer to the approach taken by color.js with proper gamut mapping between color spaces and compatibility with CSS colors. Although I would like to leverage CSS colors as much as possible and almost certainly not have color.js itself as a direct dependency.

@nickmcintyre
Copy link
Member

nickmcintyre commented Jan 3, 2024

RFC 2.0

@limzykenneth thanks for inviting me to comment! Here are some initial thoughts on the RFC:

  • Modularity: This is a great goal. D3 comes to mind as a model to follow.
  • Renderers: I like the idea of the minimum p5.js bundle including p5.Element + p5.MediaElement + maybe p5.Renderer2D.
  • DOM: Building on the point above, I propose centralizing all the DOM functions from src/dom/dom.js within src/core/p5.Element.js and moving p5.MediaElement to its own file.
  • Async: I’d love to see a few examples before sharing an opinion.
  • Color: I propose adding a function to simulate color blindness.
  • Math: I suggest implementing p5.Vector and p5.Matrix from scratch with a limited scope (core graphics/animation/simulation). Their implementations should strike a balance between compatibility with existing sketches, beginner-friendliness for users, developer ergonomics, performance, and extensibility.
  • Reference: I’m curious if we can make the process friendlier for contributors. Building the full website to preview changes isn’t fun.
  • p5.Table: +1 for retiring this class. I suggest looking to d3-array for inspiration.
  • Data: From the Data group, retire the entire Dictionary (e.g., p5.TypedDict) and Array Functions (e.g., append()) sections.
  • map(): consider renaming this function to remap() to avoid confusion with Array.prototype.map() and JavaScript's Map object.
  • range(): yes please!
  • Static mode

@limzykenneth
Copy link
Member Author

@nickmcintyre I'll share some more complete code examples after this week or so but I'll share some simple ones below, they are all working with the working branch currently.

  • Modularity - Will go more towards Dayjs but d3 is somewhat similar. Will share code for this soon (it is mostly working already)
  • DOM - I really want to break it up into smaller pieces because at it currently stands it is too big of a file to live only in one file
  • Async - see example
let img;

async function setup(){
  createCanvas(400, 400);
  img = await loadImage("./Assets/cat.jpg");
}

function draw(){
  background(200);
  image(img, 300, 300, 100, 100);
}
  • Color - color blindness mode sound like a great idea!
  • Math - Can use help to build out this proposal more certainly
  • Reference - This should come after we have the new website up, we can just take the reference bit of the new website and keep a copy here for preview
  • Data - Yes to retiring these as well same as p5.Table
  • map() - Definitely worth considering, might need to checkout how other library does it if they have similar function
  • Static mode - Can you clarify what this means?

@davepagurek
Copy link
Contributor

davepagurek commented Jan 3, 2024

If we can await loadJSON(), does that mean we can fix #2154 and have loadJSON return an array when the data is an array?

Also, I hope to get the time to make a more full proposal for this soon, but I'm hoping to refactor our built-in shaders to make them easier to use as a starting off point for making your own shaders, and to enable third party material libraries (#6144) that don't go out of date when we tweak our shaders. An example I had posted on an earlier version of this rfc went something like this:

const myShaderGraph = p5.RendererGL.lightingShaderGraph.fillColor.replaceInput(`
  uniform float millis;
  vec4 makeColor() {
    return vec4(sin(millis)*0.5 + 0.5, 0.0, 0.0, 1.0);
  }
`);
const myShader = myShaderGraph.build(p5);

@limzykenneth
Copy link
Member Author

@davepagurek Yes, awaitable loadJSON should be able to return proper arrays.

For the shaders and any WebGL related proposals, you can file a PR against the working branch RFC document when you are ready.

@GregStanton
Copy link
Collaborator

Thanks for inviting me to comment @limzykenneth! This seems like a really great initiative. I jotted down thoughts about the individual proposals, and I have notes on new proposals of my own. But my first concerns are the overall process and timeline, since we only get one shot at 2.0.

Concerns

Under the proposed timeline, the community would have about a month to propose and agree on API changes that potentially can't be undone for the next four years or more. This doesn't seem like a lot of time, considering that many of us may have overlooked opportunities for 2.0 because of the restrictions of 1.x. Some of the changes to the internals may also take a reasonable amount of time to decide on and implement.

For context, I personally would love to see changes merged by April. I think it'd help a lot with the add-on library I've been working on. Overall, though, going fast seems like more of a risk. It may take time to really get the word out about this effort, to provide a streamlined process for new proposals (e.g. with issue templates), and many other things.

Adjustments?

  1. Extend the three-month timeframe to six months? Or 12? (I'm not sure if there are any hard time constraints.)
  2. Pay a small team of community members to put in regular hours, help lead volunteers, and accelerate the effort?
  3. Freeze all work that doesn't involve a systemic or breaking change, to focus efforts on getting to 2.0?

@nickmcintyre
Copy link
Member

@limzykenneth thanks for the feedback. Here's what I'm thinking for a couple of points/questions you posed:

  • DOM: I'll refine this proposal a bit.
    • p5.Element picks up several new methods in src/dom/dom.js. For example, p5.Element.changed(). The entire class should be defined in src/core/p5.Element.js.
    • p5.MediaElement should be defined in its own file.
    • p5.File should be defined in its own file.
    • Top-level functions such as select() and createDiv() should be defined in src/dom/dom.js or a few more focused files.
  • Async: That's what I figured.
    • We should check in with more educators to get their opinions. This change would introduce new syntax and several new concepts for beginners. It could be OK, but we need more opinions.
    • Anecdotally, I've had success explaining await to middle and high school students using a version of Turtle graphics I made for the browser.
    • If we go this route, I propose dropping callbacks and applying a pattern like this instead:
let img;

async function setup() {
  createCanvas(400, 400);

  // Load and preprocess the image.
  await loadCat();
}

function draw() {
  background(200);
  image(img, 300, 300);
}

// A function to load and preprocess a cat image.
async function loadCat() {
  img = await loadImage("assets/cat.jpg");
  img.resize(100, 100);
  img.filter(GRAY);
}
  • Static mode: We shouldn't require absolute beginners to define setup() and/or draw(), similar to Processing. We should make it possible to write sketches like the following without calling new p5() at the top of a sketch:
// Create a drawing canvas.
createCanvas(400, 400);

// Draw a circle.
circle(200, 200, 50);

Making this possible could eliminate common sources of friction and misconceptions, especially in early lessons. @MsQCompSci @calebfoss what do y'all think?

Timeline

+1 for taking a little extra time. To echo @GregStanton, the 2.0 release could be a good way to engage a broader cross section of the community. It could also help to organize/prioritize contributions for Processing Foundation Fellowships and GSoC.

I'm all for making 2024 the year of p5.js 2.0 and releasing on Jan. 1, 2025.

@limzykenneth
Copy link
Member Author

limzykenneth commented Jan 4, 2024

Just a quick note about timeframe (I'll comment on the others later next week as I have a busy weekend/early week coming up), while I agree that taking a bit more time would be great, @Qianqianye and I were both keen on getting a release in April. I think it would be great to have at least something more concrete available by April and I'm not entirely sure about letting this progress for a whole year considering the probable pause we'll have on all other feature developments on 1.x.

I will have a chat with @Qianqianye probably next week or the week after to consider some options and will get back to you all. That being said, I don't want to impose a very strict timeline either and would be happy to proceed swiftly but organically.

@davepagurek
Copy link
Contributor

if it helps for reducing the timeline, the WebGL shader change I was mentioning would be an increase in modularity without breaking compatibility, so it doesn't have to be a part of the 2.0 release if my time is better spent helping along the other efforts.

@nickmcintyre
Copy link
Member

Swiftly but organically works for me. Developing the new site in tandem with 2.0 makes sense given all the changes in tooling, documentation, and so on. We should be very proactive about engaging the community. It would be helpful to assemble a diverse team of 5–10 people to vet design decisions.

@nickmcintyre
Copy link
Member

nickmcintyre commented Jan 6, 2024

My next proposals for the RFC focus on bundle size and performance. I see comments from time to time that bundle size and performance aren't that important for p5.js. We should reconsider this view.

Bundle size

  • p5.js is currently 1MB minified.
  • The minified bundle for D3 weighs in at 280KB while three.js is 671KB.
  • I don't think p5.js provides 1.5–3.6x the feature set of either of these libraries, so I'd love to shed a few hundred KB in the full build. How low can we go?
  • Reducing the bundle size would make sketches more accessible to people without high-speed connections or large data plans.
  • Doing so would also reduce power consumption from data transfer and parsing.

Performance

  • Optimizing performance would make sketches more accessible to people with modest devices.
  • Doing so would also reduce power consumption while sketches are running.
  • A few questions come to mind:
    • What kind of tooling is needed to profile performance and power consumption?
    • Who are p5.js' most performant peers? How does p5.js compare to them?
    • How do we balance complexity for developers and performance for users in a systematic way?
    • Where is the low-hanging fruit?

@limzykenneth
Copy link
Member Author

For bundle size and performance, they are specific trade offs that p5.js made for a more accessible codebase.

Much of the bundle is actually inline reference comments that are very delibrately left in the library to make the distributed source code navigable with its own full reference documentation. For minified version, we can see how far we optimize. I would however disagree that p5.js don't provide many more features than D3.js or even Three.js. D3.js and Three.js are designed to work very specifically with a DOM structure/WebGL runtime and does not provide much more beyond that including any animation runtime, event handler runtime, data loading wrappers, math functionalities (vectors, matrices, seeded RNG, etc), and much more that p5.js covers and I think should continue to cover. The modular structure, custom builds with selective modules, and ES modules are all ways that if end bundle size is important for a user, they can optimize to suite their needs.

Performance is trickier to get a handle on, p5.js I feel is not that unperformant as compared to even writing Canvas 2D code manually and when I see p5.js being compared in terms of performance, I see more of it being attributed to Javascript instead (ie. recommending using something like openframeworks for raw C++ performance). If we are to look at performance, we need concrete benchmarks so that we know what we are working with and that there are actually space to work on in terms of further optimizations, we definitely shouldn't be micro-optimizing before knowing the impacts of any optimizations without benchmarks.

@nickmcintyre
Copy link
Member

These choices are reasonable, but I think it’s worth looking at them with fresh eyes. A major release seems like a good opportunity to question everything. p5.js is creative home for me and it seems like there are opportunities to tidy up a bit.

Unminified bundle

  • It’s not clear that anyone studies the unminified bundle. The original use case may no longer be relevant, or at least it’s extremely niche.
  • It takes a JavaScript expert to understand the transformed source code in the unminified bundle. Even though the inline reference comments appear in place, a curious beginner or even a seasoned developer would have a hard time getting much use out of them.
  • Reference pages conveniently link to the p5.js source code on GitHub. The FES and the p5.js Web Editor’s Autocomplete Hinter both link to relevant Reference pages.
  • If someone wants to study the p5.js source code, they can follow links and/or download the repo.
  • 4.8MB is relatively huge. The unminified three.module.js is 1.3MB and d3.js is 587KB.
  • Given the points above, it’s worth reconsidering how we build the unminified bundle.
  • It’s also worth reconsidering the default bundle used in the p5.js Web Editor. If the FES can be made to work in a minified bundle, we should consider going that route.

Peers

D3 and three.js actually provide most of the features you mentioned. D3 is great for importing, wrangling, and interacting with data visually. three.js can load all sorts of 3D models, add them to scenes, and interact with them using a ray caster built from solid math primitives.

It’s hard to make an apples-to-apples comparison with p5.js, but I think that misses the point. It’s safe to say p5.js doesn’t provide the combined feature set of D3 and three.js. Yet p5.min.js is about the same size as d3.min.js + three.module.min.js.

I bring up those two projects specifically because they’re our peers and they excel at what they do.

Since we already plan to refactor, I propose making a concerted effort to trim all bundles as we do so. We can make the source code more accessible to developers while making the built library more accessible to users. I believe these efforts are complementary.

Performance

Agreed that micro benchmarks aren’t that helpful. It’d be interesting to design a handful of realistic benchmarks for comparison. For example, we could ask the community to re-implement all of our Examples idiomatically using other JavaScript libraries.

@davepagurek
Copy link
Contributor

Just scrolling through lib/p5.js after building the library, actual p5 code begins at line 63566 out of 121542 (over halfway through the file, by line.) This is just a rough estimate since not all lines are equal, but it gives a sense of what might be the issue. Looking at the code above there, the first big chunk is description info for FES. We can structure the 2.0 release to make that a separate import if we want to make it optional. Another large chunk is in what seems to be either dependencies or polyfills. I saw some opentype.js in there, but also a lot of code for things like promises, so I get the sense that most is polyfills, something we can maybe omit depending on what minimum browser versions we say we need to support.

It'll take some experimentation to confirm what we can actually strip away, but I don't get the sense that the p5 source code itself is actually to blame for most of this, and a lot can be solved via our build choices.

@limzykenneth
Copy link
Member Author

I think overall the size optimization will be a result of the refactors that we do and not something we need to specifically optimize for. As @davepagurek mentioned, much of the current content is the FES parameter check data and dependencies such as opentype.js and polyfills (there are a few more as well), which is also why I don't want to include additional dependencies for any of the proposals where possible (eg. Math and Color modules rewrite).

Overall feature set of p5.js is definitely much larger than what D3.js and Three.js provides out of the box simply because p5.js has a different/larger set of audience. I only listed a few of the features but there are many more such as typography, webcam camptures, day & time information, color manipulation, FES, etc. Not to mention D3 mainly interacts with the DOM but not WebGL while Three.js interacts with WebGL and not the DOM, so they are themselves quite different. That is not to say p5.js will definitely be much larger than the other two but rather it may not be realistic or accessible to aim for it, one example is that I considered moving FES out of the core p5.js bundle for this proposal but decided against it, even though it will save a lot of space, because it is against the spirit of accessibility first and the trade off in terms of file size is not worth the poor beginner experience with console messages in my opinion.


Going back to async, I think the switch to using async don't pose a significant if any increase to difficulty learning to load data in p5.js because without async, a user will still need to learn and use preload(), which in my experience is often handwaved through as "just put loading in preload()" and it will just work. Another benefit is that getting promises, async/await front loaded early will also aid in a learner's future experience in Javascript which they will have to work with the asynchronous nature of the runtime eventually.

In terms of callbacks, I'm thinking of keeping in for slightly more unusual use case.

async function setup(){
  loadImage("./cat.jpg", successCallback);
  createCanvas(400, 400);
  circle(200, 200, 100);
}

function successCallback(img){
  image(img, 0, 0);
}

The example above is a bit contrived but there could be a use case where it doesn't matter that the execution of loadImage is asynchronous and createCanvas and circle will be executed first before loadImage completes. loadImage once complete will call the callback to handle data loaded whenever it is loaded. However, technically the same can be done if we just use the promise .then() syntax so it is not entirely necessary and we need to decide which syntax would give a better experience.

@limzykenneth
Copy link
Member Author

Thanks for all the discussions so far everyone! I would like you all to forward this where possible to relevant users of p5.js (I'm specifically thinking about those who uses p5.js professionally, espeically teaching with it but flexible to consider any otherwise) so we can get more diverse opinion. I want to prioritise having voices from underrepresented circles for this process as well.

For any of the above discussion, I would also suggest opening and moving them to individual issues for focused discussion so we don't end up with a very long and hard to navigate thread here. I will keep links to them at the top post and generally use it to track progress going forward in addition to editing the RFC as well. Feel free to file PR against the RFC document as well if you want to discuss changes/addition to the proposals in a PR.

Thanks again!

@GregStanton
Copy link
Collaborator

GregStanton commented Jan 8, 2024

Thanks @limzykenneth! I propose we take a moment to flesh out the following three areas:

  1. Project management
  2. Promotional strategy
  3. Transition stewards

I'll share some initial ideas to get the ball rolling.

Project management

Problem

Right now, the RFC has limited visibility, so people are continuing to open issues as usual. Volunteers may not know whether or not they're supposed to submit pull requests to a test branch. So, we need to alert contributors to the 2.0 RFC—including those opening issues and those looking for issues to work on.

Solution

Below, I outline an approach that leverages the familiar workflow in a new way.

  1. Create an issue template for the 2.0 RFC with sections such as the following:
    1. A one-sentence description of the RFC, with a link to it.
    2. Criteria for an issue to be included as an RFC proposal.
    3. Access statement and p5.js sub-area
    4. Questions ("What's the problem?", "What's the solution?", "Is this a breaking or systemic change?")
    5. Pros and cons (a concise, running list of pros and cons based on the community discussion).
    6. An "Accepted?" section to indicate if the proposal has been merged into the RFC.
    7. Clear, concise instructions about pull requests and branches.
  2. Add bold text to all other issue templates: "Changes separate from the 2.0 RFC will be merged after the release of p5.js 2.0."
  3. Create a "2.0 RFC" issue label to help contributors find the issues we're prioritizing.
  4. Create one GitHub Issue out of each of the proposals in the original "2.0 RFC," to facilitate discussion and work.

If we accept only proposals that would be difficult or impossible to make on p5.js 1.x, that should help with the timeline. In the meantime, contributors would be free to submit, discuss, and even work on issues unrelated to 2.0, with the understanding that changes can be merged after the official release.

Promotional strategy

The transition to p5.js 2.0 is a big deal, so let's let more people know about it! In addition to helping us with the initial effort, spreading awareness now will also inform people of the possibility of breaking changes; it's good to do that as early as possible. Effective promotion takes planning and dedicated work, including the following stages:

  1. Identify places to spread the word: mailing lists, the p5.js Discord, the Processing Discourse, X, YouTube, Reddit, Instagram, Hacker News, etc.
  2. Create language and visuals for announcements, with a clear call to action (e.g. submit or review proposals).
  3. Publish the announcements and, on each of the platforms, engage with people who respond.

Transition stewards

For a major effort like this that goes beyond regular maintenance and enhancements, I think it makes sense to form a team of "transition stewards" to assist with the transition from 1.x to 2.0. The idea is to assemble a group of people who can dedicate time to project management, promotion, and (as @nickmcintyre suggested) vetting design decisions. All of this would help with the timeline.

Here are some specific tasks:

  • Help organize and run real-time online meetups from different time zones, for general discussion or even code sprints.
  • Refine development priorities and criteria for inclusion in the 2.0 RFC.
  • Develop and update issue templates (as proposed above).
  • Monitor progress and update the projected release date.
  • Flesh out the original RFC proposals and turn them into compelling GitHub issues.
  • Promote the RFC in various channels (as proposed above).
  • Design and promote guidance to help users navigate the upgrade.

We could potentially identify specific roles for each steward, but I just want to get the general idea across for now. To make this leadership opportunity more accessible to those who cannot otherwise afford to commit regular hours, I also propose that the transition stewards be compensated as contractors, if it's possible to set that up quickly enough. It's difficult to think of a more effective use of funds.

Edit: Added point about upgrade guidance, based on this comment by @kjhollen.

@KeyboardSounds
Copy link
Contributor

I've written up a proposal here for talking about whether we should consider esbuild as an alternative to Vite. I think this a separate discussion to the bundle size one above since a lot of it revolves around developer experience, but I'm not 100% sure.

@limzykenneth
Copy link
Member Author

In terms if management and promotion, I'll address them briefly separately for now.


Management

Having specific issue template for RFC related issues is a great idea and I'll accept PR to do so. We can also consider replacing the "New Feature Request" template to be the RFC proposal template. The "Existing Feature Enhancement" template may still be able to be kept around for any 1.x related feature update if necessary, the "Bug Fixes" template should be kept around but noted to only apply to 1.x.

A label for issues will definitely help as well. I'm also thinking of using GitHub Projects to help manage the overall task but that may prove more useful further down the line when we start working on implementation.

For stewarding I want to decide this at a later stage when we have finalize any specific proposals, ie. I want to prioritise assigning people who have been involved in discussions of specific proposals for this. At the same time I want to make sure we have broad voices and representation in terms of stewardship.


Promotion

Official channels will definitely be valuable to promote this effort. I will liase with @Qianqianye in the coming days when we are both available to discuss official channels' promotion (we are both away for a bit till the next day or two). For channels such as Discourse forum and Discord, any of you can definitely start a thread/channel for this, I'm not personally active on any of them and I'm happy with any of you to take on leading discussions there. I would like to consolidate discussions on GitHub though (mostly for posterity) so any discussions on other channels ideally would be summarised/formalized on GitHub eventually.

To touch on also the question of funding, I don't have any direct visibility on this and will discuss with @Qianqianye about sources from PF if applicable, while at the same time I personally would not like fundings from any third party sources just for idealogical reasons. I want p5.js 2.0 to be fully a community led project and not some project that is "made possible by ...", but that's just me possibly being unreasonable/stubborn.

Also to say that we currently have a separate funded project by STF on the website and documentation revamp (we are not allowed to use that funding for 2.0) which will also eat into the time that many core contributors have here depending on the detailed scope (or possibly not, a bit too early to tell for sure). That said 2024 will be a busy year for p5.js and I'm super glad to have everyone onboard here.

@GregStanton
Copy link
Collaborator

GregStanton commented Jan 10, 2024

Hi all. I just saw that @mohitbalwani posted #6721 about an outdated, verbose pattern for setting default parameters, and there may be other outdated code like this lurking around. Fixing these kinds of issues is one of the three stated goals of the current RFC: "Update p5.js to use more modern JavaScript conventions, both in terms of its internal implementation and the interface it exposes to the user." But, I don't think any current RFC proposal is specifically geared toward addressing these kinds of issues.

Larger modernization proposal?

How about we create a proposal dedicated to modern syntax upgrades? We may define "modern syntax" to be any syntax introduced in ECMAScript 2015 (aka ES6) or later. To make this manageable, we could break it down into sub-issues like var declarations, default parameters, and private properties.

Justification

Newer developers will tend to be less familiar with old JavaScript conventions, so modernizing the codebase should make it more accessible. Although this type of work could be done after the move to 2.0, it may make sense to do it now, since we're (hopefully) going to assemble a team of stewards who can lead efforts on systematic, overdue changes like these.

Anyone want to lead this?

I'm making this mini-proposal here since writing up a full proposal may take some time, and I'm not sure yet when I'd be able to do it (I already have a backlog of proposals to publish). Does anyone want to write this up? Leading this issue may require good project management skills, since we'd need to identify a range of sub-issues and help a group of volunteers to systematically address each one.

@GregStanton
Copy link
Collaborator

GregStanton commented Jan 10, 2024

Thanks for your thorough response @limzykenneth!

I don't have write access to be able to create a "p5.js 2.0 RFC" label, but I can put together a pull request to add a new template, to update the existing templates, and to prominently describe the proposal submission process in the RFC itself. After that, I'd be happy to make announcements on Discord and Discourse that direct any substantive conversation to GitHub. Before I can start, I have a couple questions to ask.

1. Can we agree on acceptance criteria for the RFC template?

To help contributors understand which proposals are suitable for the RFC, I'd like to provide acceptance criteria at the top of the template. I think the following criteria are narrow enough to make the 2.0 release manageable but broad enough to include all important work:

This proposal will be accepted if it has community support and involves at least one of the following types of changes:

  • Breaking change:
    • Description: Add-on libraries or sketches will work differently even if their code stays the same.
    • Example: Changing the API to make default behaviors more consistent.
  • Systemic change:
    • Description: Many features or contributor workflows will be affected.
    • Example: Setting up a new build, test, or documentation system.
  • Overdue change:
    • Description: Modifications will be made that have been desirable for a long time.
    • Example: Updating old code with modern syntax.

2. Can we agree on pull request and merge policies?

I propose we explain the pull request and merge policies in special notes on each of the issue templates.

p5.js 2.0 RFC template

"Note: If approved, a feature branch for this proposal will be created using the test-exploration branch as a starting point."

The goal here is to concisely inform contributors that there will be a slightly different process than usual. It'd be nice if this note were more precise, but I'm not sure I understand the plan: Will you create the feature branch once a proposal is approved, @limzykenneth?

Existing Feature Enhancement and New Feature Request templates

"Note: We are currently prioritizing proposals for p5.js 2.0. Work on this issue may begin after that version is released, provided there is community support."

This note lets contributors know they can still submit ideas that fall outside the scope of the RFC.

Found a Bug template

"Note: Any pull requests for this issue should be submitted to the main branch."

This may be a helpful clarification, since substantial work will be happening on other branches at the same time.

@limzykenneth
Copy link
Member Author

limzykenneth commented Jan 12, 2024

@GregStanton I can create the label (p5.js 2.0) for this.

I think for the acceptance criteria, what you have is a good starting point but at the same time I want it to be a bit more focused as well, in that it should be clear what kind of proposal may be considered and what won't be in terms of what it does. For example, we are not likely to introduce completely brand new features (such as controller API) but we are likely to consider refactoring/redesign of existing feature. I'm not sure how best to word this so will take any suggestion.

For work on implementation once a proposal is finalized, someone will be assigned to lead the implementation (from the people who contributed to the discussion). They can then create a new feature branch off of the dev-2.0 branch to implement it before merging it back with a PR, this can happen on a fork as well. In other word, dev-2.0 will be the working branch for p5.js 2.0 until we release and any PR towards 2.0 should be filed against it.

@limzykenneth
Copy link
Member Author

@GregStanton I haven't have the chance to look at the vertex proposal yet so can't say too much on that point for now. I'm a bit worried it might introduce too much breaking changes but I need to review it to know if that is the case.

For something like p5.Geometry but in 2D, that's where I'm thinking about the potential overlap between p5.Graphics and this proposed PShape. p5.Geometry make sense because it collect elements in 3D space where p5.Graphics cannot replicate in WebGL mode but in 2D mode p5.Graphics already handily captures series of draws. It feels like PShape will be a more limited version of p5.Graphics (that can only handle shapes and geometries but things like images/videos/etc).

I don't think currently there is capacity to work on a SVG renderer and p5.js 2.0 will still retain just the current 2 renderers. The renderer proposal mainly seeks to formalize the current structure and is not exactly inviting additional modifications. I can create the issue for the renderer proposal if necessary but I think for PShape, it is more about what feature/value it is bringing to what we have now that cannot be done any other way.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 13, 2024

Thanks so much for your reply @limzykenneth. I agree that before adding a feature to an API, it's important to consider how it provides value and fills a need. I'll definitely provide clear motivation in the proposals I'm planning to submit.

Clarifications

The full p5.Shape proposal will make things much clearer, assuming we can figure out how to make it work. I'll just provide a few clarifications for now, to prevent confusion for anyone who's following this discussion.

  1. When I mention PShape, I'm referring to an existing class in Processing. When I mention p5.Shape, I'm referring to a proposed class for p5.js. Both classes store data that define a shape, but they are significantly different.
  2. The vertex-refactoring project and the vertex API proposal are distinct. The planned p5.Shape class arises from the vertex-refactoring project, which wouldn't introduce breaking changes by itself.
  3. Whereas p5.Graphics provides a renderer that stores drawings on an offscreen canvas, p5.Shape would directly store the user input that defines a shape. (The relationship is similar to the relationship between PGraphics and PShape in Processing.)
  4. The p5.Shape class would be a fundamental part of the refactoring project, which has community support. So, I expect p5.Shape is already going to be implemented internally. The main question is whether to expose a version of p5.Shape to the user; the proposal I'm working on aims to settle that question.

Renderer proposal

Thanks for offering to publish the renderer proposal. I'll comment separately with an idea related to publishing the original RFC proposals more generally.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 13, 2024

@limzykenneth: You previously commented that "This thread itself I think is definitely getting a bit too crowded and I'm thinking of a better way to handle these discussions..." I'd like to help solve this problem, so I drafted a meta proposal that I could submit through the RFC proposal form; we could use the meta proposal to tag stewards and ask if they can help. I've included the draft below. If it looks good to you, I'll submit it and replace the draft in this comment with a link. (I'm asking you first since I'm guessing you wrote the original proposals.)

Update: The meta proposal is live.

@limzykenneth
Copy link
Member Author

@GregStanton I think this proposal makes total sense and is well worth trying out. Only a couple things I would like to improve where possible/reasonable.

  1. GitHub Projects - There is actually one that I'm using but it is currently private and I can't change its permission. Will see if @Qianqianye can do it but if not I'll just create a new one instead.
  2. It would be nice if we can somehow have the discussion available outside of GitHub. GitHub, even for p5.js, has a certain demongraphic and so is not necessarily the most inclusive platform, nor can any one platform by itself be realistically.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 14, 2024

Thanks @limzykenneth! I'll go ahead with the meta proposal once we finish discussing your feedback. It sounds like using GitHub Projects will work out one way or another, so the main thing to figure out is how to facilitate outside discussion. I'll share some ideas below.

Discussion platforms

I think you made a great point: there are likely many users and members of the community who could provide great feedback but aren't on GitHub. As you indicated, it's hard for any one platform to meet all of our requirements. So, for the sake of project management, I think it would make sense to use GitHub Issues for each proposal, and to expand outward from there:

  • We could reach out to @SableRaf to brainstorm ideas for Discourse. One option may be to require proposals to be submitted through the GitHub proposal form, and to encourage proposal authors to create a version on Discourse. Requiring versions on both platforms would add an extra step that may discourage proposal submissions. We could ask those who do create a version on Discourse to link to it from the GitHub version, and vice versa.
  • We could also encourage proposal authors to share a link to their issues on Discord. Maybe others who are active on Discord, like @davepagurek, will have ideas about how best to coordinate proposal discussions there, if at all? Beyond sharing a link to GitHub, it's less obvious to me how to manage proposal discussions on Discord.
  • In a similar way, we could encourage issue authors to discuss their proposals in other settings (e.g. local meetups or their own social media accounts). In those cases, we'd need to rely on them to summarize what they learn in the GitHub issue.
  • We could also set up online video calls, as discussed before. I'm not sure where we are with that.

A decentralized approach like this may be the best option, for a couple reasons. First, each proposal author will tend to be in the best position to manage discussions on their own proposals. Second, encouraging authors to promote their proposals on the platforms they use would encourage a diversity of discussion formats, and therefore a diversity of voices.

Does this sound okay to you? If so, I could make a PR to add an optional field to the GitHub proposal form, where authors could add links to discussions on other platforms. This way, anyone submitting a new proposal will be encouraged to start discussions outside of GitHub, and it will be possible to find all the main discussions from one place. For existing proposals that are already submitted as GitHub issues, I could add a short comment on the issues to let the authors know that they can add links to related discussions in their answer to "What's the solution?"

Promotional strategy

Maybe that covers discussions by themselves, but a coherent promotional strategy may also be helpful for bringing new voices into those discussions. The first thing would probably be to issue announcements on the official social media accounts (e.g. on X) and maybe to create a user-friendly informational page on the p5.js website. Is there any interest in this? I could probably come up with a separate proposal for that fairly quickly.

Process for up-to-date lists

Before implementing any broader promotional strategies, it may make sense to streamline the process for updating the list of proposals. When that list is out of date, people visiting this page can't reasonably be expected to find the other proposals before giving their feedback. The problem with maintaining the list only in the body of this GitHub Issue is that the responsibility falls entirely on you.

It'd be easier and more effective if a few contributors could volunteer to make PRs to the RFC whenever they see a new proposal. It'd be simpler to ask proposal authors to do this, but I think it's better to keep the number of steps required to submit a proposal as small as possible. Since new proposals won't be added super frequently, just a few volunteers would be needed to stay on top of them, and submitting PRs to update the RFC with new links would be a good opportunity for beginners to make their first PRs.

A benefit of using the RFC for the up-to-date listing is that you'll be made aware of PRs to add new proposals. Then, you can just add a link to the body of this issue whenever you merge one of those PRs. Keeping a list here and in the RFC will reduce the number of links that people have to click to get what they want. If this sounds good to you, I can submit a PR to the RFC that would add a section with a list of links to the proposals that have been converted into GitHub issues, unless you'd like to do that. After that, I can ask some volunteers if they'd like to keep it updated.

@limzykenneth
Copy link
Member Author

@GregStanton

Discussion platforms

For this the main concern is around representation as it is hard to make sure that we are listening to the right people when we don't have a connection to those people, as it is not unlikely that we are connected to people similar to us. We can definitely start with organizing in the forum and Discord but I think we may need some other more proactive approach to include people.

There is no need to rush this aspect however, inviting additional proposals and comments might be a bit too hard to handle in terms of volume because of the capacity of core maintainers at the moment. And also because of the limited capacity of core maintainers at the moment, we are also going to pause of arranging the community video call for now, there will be chances that we anticipate in the future for synchronous discussions but just not for now.

Promotional strategy

This has similar issue to the above and we definitely want to take it slower both in consideration of representation and team capacity.

Process for up-to-date lists

As mentioned there is a GitHub project I'm maintaining, that has just been made public in terms of access but not public in terms of usage (so don't rely on it for now). It will require a bit of organizing but once that is done, it will be the place to keep track of list of proposals and the benefit of it will be that we can keep track of progress including when it comes to implementation. It's easier to manage than a text file and PRs in any case.


In other words, I think for now there's no need for additional big changes to what we are already doing until there is a bit more capacity for things to be reviewed in detail (we do want to review all proposals especially in terms of increasing access to the right group). @Qianqianye you can chime in on what your priority around these are as well.

@Qianqianye
Copy link
Contributor

Qianqianye commented Feb 14, 2024

Thanks @GregStanton for all the suggestions!

To provide some context, a group of p5.js contributors and maintainers, including @limzykenneth and myself, are currently working on the p5.js Documentation Organization & Accessibility project supported by Sovereign Tech Fund, that will be wrapped up by April 30, 2024. Although we aim to address 2.0 proposals promptly, the p5.js maintainer group may not have the full capacity for p5.js 2.0 until the end of April.

We are truly inspired by the substantial number of proposals received for p5.js 2.0. To ensure a thorough and thoughtful review, we'd love to invest the necessary time in the evaluation process. We have made the p5.js 2.0 GitHub project public, so we can better organize the proposal issues. Additionally, we are currently in the process of reaching out to accessibility consultants to actively participate in the p5.js 2.0 RFC process.

Outlined below is the proposed timeline for the p5.js 2.0 project:

  • February/March: Establishing access goals and defining values for p5.js 2.0
  • February/March/April: Accepting and reviewing proposals for p5.js 2.0, with a focus on accessibility and FES
  • April 11-13 (Not confirmed yet): Hosting an in-person meeting to discuss p5.js 2.0 proposals during OSACC, with the possibility of a remote participation session.
  • May/June/July: Actively implementing the selected features for p5.js 2.0
  • End of 2024: Concluding the development and finalizing p5.js 2.0.

Please let us know if you have any feedback on the timeline. We plan to incorporate promotion and video-call schedules as the 2.0 RFC progresses further.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 15, 2024

Thanks @Qianqianye and @limzykenneth for your detailed replies!

I'm excited about the new p5.js 2.0 GitHub project and the accessibility consultants. I'll go ahead and post the meta proposal, since it seems like there aren't any objections.

I do think that providing an updated list of proposals is important, and I propose a simple way to do this below. I have a small amount of feedback on the timeline as well. I'll address these points below.

Updating lists

The problem

The Processing Discourse has over 10,000 users. When they visit the forum, they see a banner directing them to this GitHub issue (#6678). Over the past month, approximately one person has clicked the link to this issue every day, on average. The problem is that, when they reach this page, they see only eight p5.js 2.0 issues listed, whereas there are currently 19 issues with the p5.js 2.0 label. Effectively, this means that a majority of the p5.js 2.0 issues are inaccessible to them, so they can't provide valuable feedback.

The solution

We can solve this problem with a single edit in the body of this issue (see below). This approach does require community members to click an extra link in order to see the list of proposals, but it's simpler, more effective, and more efficient than manually updating a list.

Old text

How can individuals provide feedback on existing proposals?

Click on one of the current proposals below, and add your comments. If you know anyone else who may be interested, it'd be great if you could tag them as well.

Discussions

New text

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

Timeline

Overall, the one-year timeline seems good to me! I did notice one detail that may be important: if the February/March/April proposal period would be the only time when community members could submit proposals, then it may make sense to start a larger promotional campaign in March. That way, the community has some time to contribute their ideas. If it helps, I'd be interested to work on such a campaign.

Edit: Under "Updating lists," I replaced the original solution that I proposed with a simpler solution. I also made some small updates throughout.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 20, 2024

@limzykenneth I just came up with a super simple solution to the problem of outdated lists. If you can copy and paste the revised text I provided into the body of this issue, community members visiting from the Processing Discourse or elsewhere will be able to access an automatically updated list of proposals, so that they can leave their feedback.

@GregStanton
Copy link
Collaborator

Hi @limzykenneth! I apologize for pinging you again, since I'm sure you're super busy.

I'm following up again because a newsletter just went out to the Processing Foundation mailing list directing them to this issue. New people are also continuing to visit this issue from the Processing Discourse banner announcement. When they get here, they'll see a list of only eight proposals, but there are currently nineteen proposals, so they won't be able to provide feedback on most of them.

I came up with a one-time, self-updating solution that would just take you a few seconds to implement. You'd just need to replace the "Old text" below with the "New text," which contains a link to an automatically updated list. I'm hoping you can do this while people are still clicking through to this page from the newsletter, or as soon as you get a chance.

Old text

How can individuals provide feedback on existing proposals?

Click on one of the current proposals below, and add your comments. If you know anyone else who may be interested, it'd be great if you could tag them as well.

Discussions

New text

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

@Qianqianye
Copy link
Contributor

Thanks @GregStanton. I update the issue with new text.

@GregStanton
Copy link
Collaborator

GregStanton commented Feb 27, 2024

Thank you so much @Qianqianye!! There are a couple of duplicate sentences. Would you mind fixing it?

Current text

How can individuals provide feedback on existing proposals?

Click on one of the current proposals below, and add your comments. If you know anyone else who may be interested, it'd be great if you could tag them as well.

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

New text

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

@Qianqianye
Copy link
Contributor

Updated! Thanks @GregStanton.

@GregStanton
Copy link
Collaborator

Hi @Qianqianye and @limzykenneth!

Just FYI, I sent an email to you both this morning with an offer to help lead p5.js 2.0 efforts, starting during the proposal period.

I'm eager to commit significant, regular hours to the project, especially since the p5.js maintainers and other contributors will have reduced capacity over the next couple of months (due to the concurrent Documentation Organization & Accessibility project). In the email, I request financial support to be able to do this; for example, @limzykenneth mentioned previously that he could look into whether the Processing Foundation might be able to help out.

I thought I'd mention it here since it's relevant to the overall discussion, and also because I'm not certain I have the right email addresses for you both! For anyone else who is interested in this idea of financial support for "transition stewards," I outlined an early version of the idea in a comment above.

@limzykenneth
Copy link
Member Author

@GregStanton We will follow up on your email later today or tomorrow.

@RandomGamingDev
Copy link
Contributor

RandomGamingDev commented Mar 3, 2024

Here are some features that I think should be added with their issues linked below:

Using an external math library for p5.js's mathematical operations

The addition of automatic batching to p5.js

@GregStanton
Copy link
Collaborator

GregStanton commented Mar 3, 2024

Hi @RandomGamingDev! Thanks for your work on these issues.

The automatically updated list of p5.js 2.0 issues

We recently updated the p5.js 2.0 FAQ in the body of this issue (#6678) to help the community find p5.js 2.0 proposals:

How can individuals provide feedback on existing proposals?

View the updated list of p5.js 2.0 proposals, click any of the proposals that you're interested in, and add your comments. If you know anyone else who may be interested in an issue, it'd be great if you could add a comment on the issue to tag them.

That link will always stay up to date automatically, since new proposals for p5.js 2.0 automatically receive the p5.js 2.0 label. So, anyone who clicks that link will see the two proposals you cited (#6765 and #6805), along with the other issues related to p5.js 2.0. When they visit the math library proposal, they'll see your link to the supporting issue (#6527) at the top. Maybe at the top of the batching proposal, you could include a link to its supporting issue (#6279) in a similar way? If you can direct new discussion to the 2.0 proposals (when possible) and let people know that the other issues contain supporting background information, that should be helpful.

The currently out of date lists of p5.js 2.0 issues

The markdown version of the RFC and the p5.js 2.0 GitHub project are not currently being kept up to date. However, the FAQ is the main place for everyone in the community to learn about proposals and issues related to p5.js 2.0. It's featured at the top of the issues page, and announcements point here as well (e.g. the Discourse banner announcement and the Processing Foundation's February newsletter).

@RandomGamingDev
Copy link
Contributor

RandomGamingDev commented Mar 3, 2024

That link will always stay up to date automatically, since new proposals for p5.js 2.0 automatically receive the p5.js 2.0 label. So, anyone who clicks that link will see the two proposals you cited (#6765 and #6805), along with the other issues related to p5.js 2.0. When they visit the math library proposal, they'll see your link to the supporting issue (#6527) at the top.

I didn't post the comment referencing the issues due to not thinking that they were easily accessible, but in order to bring more attention to them since they're receiving drastically less attention than they should be considering how large the issues are. This is especially prevalent in suggestion for using an external math library since there was little to no response from those who opposed it despite the response I wrote to those oppositions as requested by them and the fact that they're still active within other parts of p5.js.

Maybe at the top of the batching proposal, you could include a link to its supporting issue (#6279) in a similar way?

The original issue didn't have much data or much of a response, but yeah it'd be best to have that reference even if it's just to prevent confusion between issues so I just added that to the RFC 2.0 version of the issue.

@GregStanton
Copy link
Collaborator

Oh, I see what you mean @RandomGamingDev. For my part, I'll reply with my latest feedback as soon as I get a chance. If you ever want to tag me or reach out on Discord to follow up, please do!

@limzykenneth
Copy link
Member Author

Hi everyone, just an update and some clarification as my previous messagings might cause some confusion or misunderstanding. We are not seeking to move this p5.js 2.0 project forward very quickly at this point and would like to take it slow, it might be slower than what some might expect but we are not working towards any time pressure here.

Both @Qianqianye and I would like to be involved in reviewing all proposals, while we currently don't have full capacity to do so due to the more time sensitive STF funded project around documentation going on currently, we are also not seeking additional help at this point as we feel it is important that we are responsible for the reviews. That being said, the community can still, are are highly encouraged to, create new proposals and further discussions on existing ones. Usually the more a proposal is discussed and potential problems fleshed out, the easier it will be later on for the decision to either accept or not accept it. My personal suggestion for contributors interested in 2.0 is to review the existing proposals and consider how the proposal can make p5.js easier to use/better for you or how it can possibly make p5.js harder to use/worse for you?

@Qianqianye has shared a rough timeline we are working with but again as mentioned we don't have any time pressure on this and we don't want to rush it, so I won't commit to a strict timeline here. I will continue to look at proposals and ideas as they come when I have capacity to.

A final point is to highlight again that the p5.js Access Statement as well as Code of Conduct still apply. We will continue to monitor and enforce these as priorities.

@GregStanton
Copy link
Collaborator

Hi @Qianqianye and @limzykenneth! During OSACC, there was some discussion about when proposals might stop being accepted. The proposed outline indicates that this may happen soon, so I thought I should ask my questions about this now. I understand that you may both be busy with the p5.js Documentation Organization & Accessibility project; for now, if you have time to answer the first question, that'd be super helpful.

Questions

  1. Would it be possible to clarify whether or not there will be any hard submission deadlines for p5.js 2.0 proposals at the beginning of May?
  2. Going forward, would it be possible to issue a broader announcement with a date and time when proposals will no longer be accepted (hopefully closer to June than May 1)?

The previously proposed outline

Outlined below is the proposed timeline for the p5.js 2.0 project:

  • February/March: Establishing access goals and defining values for p5.js 2.0
  • February/March/April: Accepting and reviewing proposals for p5.js 2.0, with a focus on accessibility and FES
  • April 11-13 (Not confirmed yet): Hosting an in-person meeting to discuss p5.js 2.0 proposals during OSACC, with the possibility of a remote participation session.
  • May/June/July: Actively implementing the selected features for p5.js 2.0
  • End of 2024: Concluding the development and finalizing p5.js 2.0.

Please let us know if you have any feedback on the timeline. We plan to incorporate promotion and video-call schedules as the 2.0 RFC progresses further.

Mini-proposal: Set a submission deadline, make it later than May 1, and publicize it

Reasons in favor of this mini-proposal are listed below.

  1. Many contributors may be unaware that the time to submit proposals is nearing an end. The proposed outline quoted above is taken from a comment that appeared deep in this discussion, and only a few in the community were able to attend OSACC.
  2. Anyone (including myself) who has been working on draft proposals may not submit them in time if they're unaware of the deadline.
  3. The community will have increased access to the proposal process. Specifically, a later submission deadline would provide time for the promotion and video calls mentioned in the proposed outline above. It may then be possible to provide a unique opportunity: pairing wider community members with GitHub contributors who can help them submit their ideas.

I'm also tagging @davepagurek and @nickmcintyre so that they're aware of this conversation. Thanks for your time and consideration!

@rsodre
Copy link

rsodre commented Apr 25, 2024

I'm rarely in the mood to write proposals, but could do a mini-proposal.
Would be lovely to have a HAIR line type, simple GL_LINES with a width of 1 (it can't be any thicker anyway)
The current line shader is great, but there's a lot of unnecessary CPU and GPU computation when we need just the thinnest lines possible.

@limzykenneth
Copy link
Member Author

Would it be possible to clarify whether or not there will be any hard submission deadlines for p5.js 2.0 proposals at the beginning of May?

Going forward, would it be possible to issue a broader announcement with a date and time when proposals will no longer be accepted (hopefully closer to June than May 1)?

Probably easier to answer both at once. We haven't quite decided on dates for 2.0 quite just yet as we are still completing the final stages of the documentation and website project toward April 30, after that we will have more head space to plan 2.0 more.

After the submission deadline, it is not so much that we won't accept any more proposals but rather our focus will shift to planning and implementation. Even after 2.0 is released, the usual flow of feature requests will still apply, just without the immediate possibility of making breaking changes if necessary. The new module system is also aimed to provide much flexibility when it comes to extending/replacing parts of p5.js so not all features needs to be in the core library. We will make another announcement with the proposal submission deadline, and since we will decide this in May, it will likely be later in May rather than early May.

@GregStanton
Copy link
Collaborator

Thanks so much @limzykenneth! That helps a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests