p5.js 2.0 RFC #6678
Comments
Color ModuleThe 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. ProposalI 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? |
|
@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. |
RFC 2.0@limzykenneth thanks for inviting me to comment! Here are some initial thoughts on the RFC:
|
|
@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.
let img;
async function setup(){
createCanvas(400, 400);
img = await loadImage("./Assets/cat.jpg");
}
function draw(){
background(200);
image(img, 300, 300, 100, 100);
}
|
|
If we can 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); |
|
@davepagurek Yes, awaitable For the shaders and any WebGL related proposals, you can file a PR against the working branch RFC document when you are ready. |
|
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. ConcernsUnder 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?
|
|
@limzykenneth thanks for the feedback. Here's what I'm thinking for a couple of points/questions you posed:
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);
}
// 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. |
|
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. |
|
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. |
|
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. |
|
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
|
|
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. |
|
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
PeersD3 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. PerformanceAgreed 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. |
|
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. |
|
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 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 |
|
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! |
|
Thanks @limzykenneth! I propose we take a moment to flesh out the following three areas:
I'll share some initial ideas to get the ball rolling. Project managementProblemRight 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. SolutionBelow, I outline an approach that leverages the familiar workflow in a new way.
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 strategyThe 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:
Transition stewardsFor 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. |
|
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. |
|
In terms if management and promotion, I'll address them briefly separately for now. ManagementHaving 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. PromotionOfficial 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. |
|
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 JustificationNewer 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. |
|
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:
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
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
This note lets contributors know they can still submit ideas that fall outside the scope of the RFC. Found a Bug template
This may be a helpful clarification, since substantial work will be happening on other branches at the same time. |
|
@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 @GregStanton @davepagurek and everybody else interested in the licensing proposal: There are now two (competing) proposals:
I've refrained from suggesting switching to MIT in the second proposal, since it seems that switching to MIT could be in conflict with p5's access goals, since more privileged groups could benefit more over marginalized groups from this change. The second proposal's goal is thus to transition to a simpler, less complex license. |
|
Thanks @limzykenneth! I appreciate you pointing out the potential overlap between a p5.Shape proposal and the renderer proposal. Based on the use cases we have in mind, my understanding is that any overlap would be indirect. Below, I'll give a very brief version of the proposal that @davepagurek has been helping me to develop, so that you can tell me if I'm wrong, and so that you're aware of what we're working on. I'm tagging @rsodre here too, since they may be interested as well. The problemThe proposal is motivated by a couple of limitations:
The solutionIn the vertex-refactoring project, we've already planned out an internal p5.Shape class. By adding a few properties and methods and exposing p5.Shape to the user, we can give them access to the essential built-in features (these are not specific to a renderer), while also making it easier for them to develop their own features. We also hope to create a more consistent experience than we get with the current combination of Relationship to PShapeIn the spirit of the rest of p5.js, I'd like to take inspiration from Processing's PShape while reserving the option to do things differently according to our context. One feature of PShape I'm hoping to keep is the ability to store the full range of shapes made with Relationship to SVG and other file formatsAs p5's native shape class for both 2D and 3D shapes, p5.Shape would ideally be compatible with SVG paths, in addition to OBJ and STL geometries. This is another area where Processing's PShape provides inspiration, since it can already store data loaded from SVG and OBJ shapes. More specifically, the goal is to make p5's existing features more accessible and consistent. Users may be surprised to find that p5.js can already import 3D shapes via two file formats (STL and OBJ), but unlike Processing, it cannot import 2D shapes at all; the addition of Relationship to the renderer proposalSince we're not working on converting to SVG for rendering, my understanding is that these changes wouldn't overlap directly with the RFC's renderer proposal. Even if my understanding is correct, it still seems reasonable to consider how these features would fit together. Would it be possible to post the renderer proposal through the p5.js 2.0 RFC proposal form, so that we can ask questions and continue the discussion without clogging up the comments here? |
|
@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. |
|
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. ClarificationsThe full
Renderer proposalThanks for offering to publish the renderer proposal. I'll comment separately with an idea related to publishing the original RFC proposals more generally. |
|
@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. |
|
@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.
|
|
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 platformsI 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:
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 strategyMaybe 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 listsBefore 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. |
Discussion platformsFor 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 strategyThis 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 listsAs 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. |
|
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:
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. |
|
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 listsThe problemThe 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 solutionWe 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
New text
TimelineOverall, 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. |
|
@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. |
|
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
New text
|
|
Thanks @GregStanton. I update the issue with new text. |
|
Thank you so much @Qianqianye!! There are a couple of duplicate sentences. Would you mind fixing it? Current text
New text
|
|
Updated! Thanks @GregStanton. |
|
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. |
|
@GregStanton We will follow up on your email later today or tomorrow. |
|
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 |
|
Hi @RandomGamingDev! Thanks for your work on these issues. The automatically updated list of p5.js 2.0 issuesWe 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:
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 issuesThe 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). |
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.
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. |
|
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! |
|
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. |
|
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
The previously proposed outline
Mini-proposal: Set a submission deadline, make it later than May 1, and publicize itReasons in favor of this mini-proposal are listed below.
I'm also tagging @davepagurek and @nickmcintyre so that they're aware of this conversation. Thanks for your time and consideration! |
|
I'm rarely in the mood to write proposals, but could do a mini-proposal. |
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. |
|
Thanks so much @limzykenneth! That helps a lot. |
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.
The text was updated successfully, but these errors were encountered: