search

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.59k stars 3.31k forks source link

p5.js 2.0 RFC #6678

Open limzykenneth opened 9 months ago

limzykenneth commented 9 months ago

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)

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 commented 9 months ago

Color Module

The user should be able to

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 commented 9 months ago

@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 commented 9 months ago

RFC 2.0

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

limzykenneth commented 9 months ago

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

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 commented 9 months ago

If we can await loadJSON(), does that mean we can fix https://github.com/processing/p5.js/issues/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 (https://github.com/processing/p5.js/issues/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 commented 9 months ago

@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 commented 9 months ago

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 commented 9 months ago

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

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:
```js
// 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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

Performance

limzykenneth commented 9 months ago

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 commented 9 months ago

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

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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:

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

GregStanton commented 9 months ago

Thanks @limzykenneth!

Narrowing the focus sounds good to me. I've updated the language to reflect your feedback. If we decide this version is reasonably close to a final draft, I'll go ahead and flesh out the rest of the 2.0 RFC template in a pull request, and I can update the other templates as well. We could discuss any detailed adjustments on the pull requests themselves.

p5.js 2.0 RFC template

I've revised the acceptance criteria to emphasize how existing and new features will be treated differently:

Acceptance criteria

This proposal will be accepted if the community determines it would improve an existing feature through one of the following types of changes:

  • A 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.
  • A systemic change:
    • Description: Many features or contributor workflows will be affected.
    • Example: Setting up a new build, test, or documentation system.
  • An overdue change:
    • Description: Modifications will be made that have been desirable for a long time.
    • Example: Updating old code with modern syntax.

In order to focus the community's efforts, proposals for new features will typically not be incorporated into the RFC. A New Feature Request may still be submitted, but it will only be considered after the release of p5.js 2.0.

Instead of a "Note," I've also added a more descriptive heading regarding the implementation, and I've revised the description so that it's more accurate:

Implementation process

If this proposal is approved, a contributor who has participated in the discussion will be assigned to lead the implementation, which will happen on the dev-2.0 branch."

Existing Feature Enhancement and New Feature Request templates

This is the same as before, except for the new heading:

Implementation process

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

Found a Bug template

This is also the same as before, except for the new heading:

Implementation process

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

limzykenneth commented 9 months ago

@GregStanton Looks ok to me, you can go ahead and create the PR. We can revisit later if necessary.

limzykenneth commented 9 months ago

I would like to start running synchronous online meet ups to discuss different aspects of the proposals and the first one I would like to do is around the build system, modular system, and addon library system as they are all somewhat related (#6716).

The format of this will depend on how many people will be joining, if there are too many people joining, it will probably be difficult to do a full roundtable discussion so we may use the call chat to coordinate. We'll probably be a bit ad-hoc for this I would imagine.

To get this started, for those interested in joining this discussion, can I get a quick indication of what timezone you are in and I will set up a when2meet link in a couple of days accounting for timezones as much as reasonable. @davepagurek @GregStanton or anyone else, if you can help send the word out on Discord for this it would be great as well.

GregStanton commented 9 months ago

Thanks @limzykenneth! I'm on it! Also, I just submitted a new proposal for the RFC, literally a minute or two ago.

Edit: Oh, and I'm on Mountain Time (Denver, Colorado in the US).

davepagurek commented 9 months ago

Thanks for getting the ball rolling @limzykenneth! I've just posted in a few places. Looking forward to the call!

nickmcintyre commented 9 months ago

@limzykenneth just posted in the Processing Discourse! I'm on Central Time (Houston, Texas in the US).

SableRaf commented 9 months ago

I got a DM from @GregStanton about pinning the announcement on the Processing Foundation Discourse. Let me know what you'd like it to say and I can make a banner post from the foundation account and pin it to the p5.js category too.

limzykenneth commented 9 months ago

@GregStanton We can reuse what you sent to Discord if it made sense for the forum. Do send @SableRaf the text when you can.

GregStanton commented 8 months ago

@limzykenneth Done! I adapted the Discord announcement for Discourse, polished it some more, and shared it with @SableRaf. I think it's going to look great!

Qianqianye commented 8 months ago

Thanks @limzykenneth @GregStanton @davepagurek @nickmcintyre @SableRaf for getting the ball rolling for the online meet up about p5.js 2.0 RFC. I'm meeting with @limzykenneth tomorrow to go through the meet up details, like how we can ensure a diverse group of attendees. We will share our follow up here tomorrow.

SableRaf commented 8 months ago

Thanks @GregStanton for the text. I have made the post on the forum. It will appear as a banner topic for all users (until they dismiss it) and will be pinned to the p5.js category for the next 6 months.

GregStanton commented 8 months ago

Wow, thanks @SableRaf!! Also, thanks for sending out the email to the forum users, and for making the invitation at the top of the announcement into a link. That was a great idea! Oh, and the heading "Your Chance to Shape the Future of p5.js" is absolutely perfect.

villares commented 8 months ago

I have a documentation change proposal, but I found this RFC processes a bit overwhelming. Are we supposed to open an issue?

Anyway, my proposal is about the reference page: https://p5js.org/reference/ and it could encompass both p5,js v1 and p5.js v2.0. The current reference page inherits its main structure from the old Processing.org reference, which has moved on since and improved quite a bit now (https://processing.org/reference/).

With a brief description next to each item/entry the reference becomes much more useful for beginners to find stuff. Also, the category names could be improved by being a bit more didactic. I thought long and hard about this issue working on the py5 reference summary (https://py5coding.org/reference), there I helped to reorganize the categories (which Processing.org didn't) and added a brief description for each item (which Processing.org did!).

limzykenneth commented 8 months ago

@villares This thread itself I think is definitely getting a bit too crowded and I'm thinking of a better way to handle these discussions that can help make it easier to jump in without needing to go through all the context that came before.

For your suggestion on changes to the reference page, it is technically out of scope for p5.js 2.0 as it is more to do with the website and not the p5.js library itself. That said, we are currently also working on a new website for p5.js which we aim to publish in a couple months, the idea of having both 1.0 and 2.0 documentation (or in fact versioned documentation) is one of the thing we are looking into already. The design itself is being worked on and we'll take on board the suggestion of short description of each item.

GregStanton commented 8 months ago

@limzykenneth: The banner announcement on the Processing Discourse is directing people to this issue. So, would you be able to update the body of the issue to reflect the new process for them? This could clear things up for contributors like @villares who have good ideas but aren't sure how to contribute them. And it may solve the problem of how to direct discussion. Maybe the body of the issue could be something like the following:

What is p5.js 2.0?

This will be the first major release of p5.js in four years. 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.

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

Essentially, any change to an existing feature will 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. Other types of changes that will be considered include systemic changes and overdue changes. The proposal form provides more details about the specific types of changes that will be considered.

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

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

How can individuals provide feedback on existing proposals?

Just 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.) To get things started, the following people are directly invited to comment...

Current proposals

  • [ ] #6716
  • [ ] #6152
  • [ ] ...

When will the online discussion meetups be held? Who can attend?

We'll post the dates and times here once we have them, and we'll send out an email to the Processing Foundation mailing list. Anyone can subscribe to receive updates by entering their email at the bottom of the foundation's home page, and anyone can attend!

Would this clear up your questions about the process, @villares?

In the long run, @limzykenneth, are you planning to turn each of the original proposals in the RFC into issues with the new proposal form, as you did with the async/await/setup issue? That'd make it easier for people to know where to comment. I personally have written up comments on each of the original proposals, but at the moment, there's not a good place to post them.

Future of the RFC document

Once proposals are accepted, maybe their access statement, problem statement, and solution statement can just be copied into the RFC, along with a link to the issue for anyone who wants to see the full discussion. Proposals that aren't accepted could go into a separate section formatted similarly.

This would be an organized way to record the decision making process for future reference, and it'd make it easy for anyone to survey all the changes that will be made, in one place. That should help with planning out the implementation process too. And it wouldn't require much additional effort.

Based on an idea from @kjhollen, maybe the entries for accepted proposals could also include "user-impact summaries"; these would describe how the changes will directly affect users. The people leading each proposal could be tasked with writing these summaries, which could later be used by the transition stewards to develop public-facing, 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).

Edits: Added additional explanation about the kinds of changes that will be accepted. Added the idea regarding user-impact summaries. Revised some wording.

SableRaf commented 8 months ago

Note for a future proposal: Replacing the "Loading" text with a css loading animation would make it look nicer and be more accessible for non English speakers.

kjhollen commented 8 months ago

Hi all, a suggestion here—would it be possible to summarize how these changes affect end-users, especially teachers? I have read through the document and it seems like a lot of what is discussed here is internal to library implementation.

It would be helpful to know if there's anything I'll need to update when I teach with p5.js in the future, after 2.0 is released. For example, will I need to cover modules when I teach with 2.0, or will this largely be invisible to beginners and not necessary to cover in class? Will the p5.js web editor include all 2.0 modules automatically? Will import statements be visible in the default sketch.js file template in the editor?

GregStanton commented 8 months ago

Hi @kjhollen!

Thanks for this idea! I think it will definitely help to have a plan for developing and issuing upgrade guidance. I've just updated two comments based on your idea:

  1. A comment on project management, promotional strategy, and transition stewards
  2. A comment on organizing and clarifying the transition process

It's not clear yet what all the essential changes will be, but I think these updates will make it easier for us to issue upgrade guidance once that's all clarified. Since p5.js 1.x will be supported with bug and critical fixes for another twelve months after p5.js 2.0 is released, there should be time to spread the word too.

P.S. We've already made progress on some of the plan outlined in the first comment. Specifically, we've developed the new issue template and updated the existing ones, we've added a p5.js 2.0 label for organizing issues, and we've started to get the word out on Discord and Discourse.

rsodre commented 8 months ago

Something I really miss from Processing: PShape

One decade later... it's never too late to do the good thing. implement PShape

GregStanton commented 8 months ago

Thanks @rsodre! I've actually been working on a proposal that will likely involve a p5.Shape class. Right now, it's looking like it will be a much smaller class than Processing's PShape, but nothing is set in stone yet. Would you mind if I contact you once the proposal is ready, to get your feedback? If so, what's the best way for me to do that? In case you want to reply to me directly, I'm on the p5.js Discord / Processing Discourse as highermathnotes/HigherMathNotes.

kjhollen commented 8 months ago

Hi @kjhollen!

Thanks for this idea! I think it will definitely help to have a plan for developing and issuing upgrade guidance. I've just updated two comments based on your idea:

1. [A comment on project management, promotional strategy, and transition stewards](https://github.com/processing/p5.js/issues/6678#issuecomment-1880547911)

2. [A comment on organizing and clarifying the transition process](https://github.com/processing/p5.js/issues/6678#issuecomment-1913480670)

It's not clear yet what all the essential changes will be, but I think these updates will make it easier for us to issue upgrade guidance once that's all clarified. Since p5.js 1.x will be supported with bug and critical fixes for another twelve months after p5.js 2.0 is released, there should be time to spread the word too.

P.S. We've already made progress on some of the plan outlined in the first comment. Specifically, we've developed the new issue template and updated the existing ones, we've added a p5.js 2.0 label for organizing issues, and we've started to get the word out on Discord and Discourse.

thanks, @GregStanton, these process updates look great!

Wondering if anyone can answer these questions in this thread, too:

For example, will I need to cover modules when I teach with 2.0, or will this largely be invisible to beginners and not necessary to cover in class? Will the p5.js web editor include all 2.0 modules automatically? Will import statements be visible in the default sketch.js file template in the editor?

I think I'd prefer if there are no changes visible to the template code in the editor's default sketch.js file to keep things simple for our users. I just want to make sure this is already the plan!

meezwhite commented 8 months ago

Hey everyone,

I wanted to initiate a discussion about something that's been on my mind: the possibility of transitioning p5.js 2.0 from LGPL-2.1 to MIT.

Now feels like a good time to talk about this, and I believe shifting to MIT could actually benefit the p5.js ecosystem. I'm not entirely sure how feasible or easy to do this would be, considering the existing code contributed by community members, was contributed to be licensed under LGPL-2.1, thus the keyword transition.

Just to be clear, I'm not pushing too hard for this. But I think it would be valuable to discuss whether moving to MIT would make sense. What do you all think?

I'm sure there are plenty of arguments both for and against this (see this issue almost 10 years ago: #293). To start, I'd like to mention two points, I can relate to.

Avoiding dual-licensing when reusing p5.js code

Let's say I want to incorporate/adapt p5.js code into my MIT-licensed project. My understanding is that my project would now be dual-licensed, with some portions being MIT-licensed and others LGPL-2.1-licensed.

If p5.js was MIT-licensed the incorporated/adapted p5.js code would still require proper attribution and inclusion of its MIT license, as stated in its attribution clause:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Encouraging adoption in commercial projects

Switching to MIT could foster increased adoption of p5.js in commercial projects. This shift might attract businesses and developers who prioritize the flexibility and simplicity offered by permissive licenses.

For instance, a company developing an interactive data visualization tool might find it more appealing to incorporate an MIT-licensed p5.js version into their project, enabling broader usage (and innovation).

Although modifying an MIT-licensed p5.js wouldn't require publishing the modified version, which might actually "hinder" innovation, this could also be currently circumvented using the addon system.

Related issues

293 #5150

limzykenneth commented 8 months ago

@kjhollen As @GregStanton mentioned changes are not finalized yet so I can't give a definitive answer but I would say pretty much nothing will need to change in terms of teaching p5.js at least for most use cases, only difference I anticipate may be data loading if we decided to go with async/await by default.

More specifically,

will I need to cover modules when I teach with 2.0

No, ES modules use with p5.js is entirely optional just to enable more semantic use in frontend frameworks via NPM. p5.js 2.0 will still work the same by including p5.js file in a script tag in HTML.

Will the p5.js web editor include all 2.0 modules automatically?

There will be a decision made later on about what modules to include in the default build of p5.js (eg. whether to include WebGL renderer by default or not), and it may very well be all modules will be included but most common ones will likely be included so things like 2D renderer, color, math, etc. In the case that there are modules made optional and not included in the default build, p5.js Web Editor can separately decide to include all modules by default if necessary.

I'm going to eventually test this on the new p5.js website but one of the idea is to dynamically import optional module as features are used, ie. automatically load in the WebGL module if the canvas is created as a WebGL canvas for example. Although this is only an idea for now.

Will import statements be visible in the default sketch.js file template in the editor?

This will not be necessary if p5.js is included with a script tag and the sketch.js file is not included in the HTML as an ES module.

In essense, the good old

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

function draw(){
  background(200);
}

starter sketch will work out of the box with no modification other than changing the p5.js version in the CDN link in the HTML script tag to say 2.0.0. This I think I will go out of the way and say is set in stone.

limzykenneth commented 8 months ago

@meezwhite Thanks for chiming in about this. To address the two points you mentioned about LGPL:

Avoiding dual-licensing when reusing p5.js code

If your project is using p5.js as a library, ie. you are not creating a derivative work from p5.js code, you can license your code however you wish including under just MIT. LGPL only affects p5.js code. If you are creating derivative work of p5.js code I think it is fair to have that code contributed back under LGPL terms, I want to avoid the case where derivative work is created on top of the work that p5.js contributors created, but never contributed back to the benefit of the p5.js community.

MIT license only require the license text to be distributed, not the derivative work.

Encouraging adoption in commercial projects

Adoption in commercial projects is not really a priority and at the same time LGPL also does not prevent the use of p5.js in any commercial projects. LGPL only applies to p5.js code and unlike GPL, does not affect code using p5.js including distributing it via any channel including commercial projects. The only requirement that need to be fulfilled is only present if p5.js' code is modified, creating a derivative work of p5.js code, then the modified version must be released under LGPL but only the modified p5.js code, not the rest of the application code.

This last restriction, as you identified, can be overcome with addon libraries

this could also be currently circumvented using the addon system.

Addon libraries uses p5.js as a library and library authors are not modifying p5.js code nor distributing a modified version of p5.js code, so addon libraries can be freely licensed.

I hope the above made sense.

limzykenneth commented 8 months ago

Sorry that I wasn't able to participate in the discussions very much recently as I have a lot of work piling up at the moment. However, to guide continued discussion a bit, I 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".

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

kjhollen commented 8 months ago

I'm going to eventually test this on the new p5.js website but one of the idea is to dynamically import optional module as features are used, ie. automatically load in the WebGL module if the canvas is created as a WebGL canvas for example. Although this is only an idea for now.

I like the sound of this!

Will import statements be visible in the default sketch.js file template in the editor?

This will not be necessary if p5.js is included with a script tag and the sketch.js file is not included in the HTML as an ES module.

In essense, the good old

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

function draw(){
  background(200);
}

starter sketch will work out of the box with no modification other than changing the p5.js version in the CDN link in the HTML script tag to say 2.0.0. This I think I will go out of the way and say is set in stone.

Great, sounds good to me. Thanks for answering all my questions @limzykenneth!

GregStanton commented 8 months ago

Thanks for your comments about the license @meezwhite!

Initial thoughts on the licensing proposal

This is an interesting topic. I do think the complexity of the current license has certain drawbacks. For example, since many in the community are not lawyers, understanding what the license actually says may be a significant impediment; in that case, they may not feel comfortable going forward even if their intended usage is allowed. In this sense, the MIT license is more accessible, because it's significantly shorter and less complex. So, I think there's room for thoughtful discussion here.

But, as you noted, the feasibility of a license transition may be an issue, and that may actually be the first concern to deal with. My initial guess is that a transition to MIT at this stage, for a project as big as p5.js, is probably going to be infeasible. Roughly, my reasoning is this: since the MIT license is more permissive, we might need to get permission from all the previous contributors before moving to it. For a sense of the difficulty, here's an example of a project that attempted to do this: https://github.com/PHPOffice/PhpSpreadsheet/issues/140 (It seems they did go ahead with it after a couple years of discussion, although I don't know if they made the change in a totally legal way.)

Since p5.js has a relatively long history at this point and quite a lot of contributors, going through a similar process would probably be quite time consuming, possibly with no change being made in the end. The project I cited discussed rewriting contributors' code somehow in order to erase past contributions from people who didn't give their consent, but that seems problematic as well.

To be clear, I may be wrong and would definitely need to look into this more! I'd like to understand these issues better and would be interested to see further discussion. My goal here is to point out difficulties that may need to be investigated.