TurboWarp
Consolidation of duplicate PRs
I'm going to try to consolidate some of the duplicate extension pull requests. This is a non-conclusive list and is subject to change. Some of these extensions will be harder to consolidate than others as they are either well-developed or both have benefits over the other. Some of these we may not even want to consolidate yet, and others are part of a bigger issue (like sensing+ or "secure" storage).
- [ ] #1354 and #1066
- [ ] #2113 and #1861
- [ ] #1617, #1432, and #1608
- [ ] #1183 and #1176
- [ ] #2087 and #1341
- [x] #1040 and #1060
- [ ] #2104 and #1122
I think a very big issue with "consolidating duplicate extensions" is that each dev has their own ideas and want to have their stake in the extension gallery. By taking down duplicates, you fuel the fire of "one extension is better than the other, so the lesser ones must be closed". If there's duplicate extensions, and none have been merged yet, I rather wait to see which one ACTUALLY gets merged before we close duplicates. It's nice to give people chances considering this repository is slow and having a chance against devs who are already on the gallery are tight.
That's not really fair. Older ones came first can should have a higher priority.
Newer ones show up higher in the list. People might not realize there's a duplicate lower.
If the older ones were merged, we wouldn't be having duplicates in the first place
I think a very big issue with "consolidating duplicate extensions" is that each dev has their own ideas and want to have their stake in the extension gallery. By taking down duplicates, you fuel the fire of "one extension is better than the other, so the lesser ones must be closed". If there's duplicate extensions, and none have been merged yet, I rather wait to see which one ACTUALLY gets merged before we close duplicates. It's nice to give people chances considering this repository is slow and having a chance against devs who are already on the gallery are tight.
See the initial comment, this issue isn't meant to rapidly close any duplicates without any care or concern. I aim to:
- Prioritize the interests and unique ideas of each developer
- Not be hasty in my decisions
- Not cause any dissension in the community
I want to be very clear that "Consolidation" ≠ "forget this PR, let's close it because there's a better one"
The whole point of this issue is to critically think about how to consolidate these extensions into something better than they would've been independently, not blindly close PRs for the sake of organization
The only duplicates that I might close hastily are those that are poorly written or purposeless, but such instances are rare. I'm trying to go about things carefully, but if you guys have other suggestions I'd be open to them.
I'm not trying to fuel any fire or cause problems, I'm attempting to do my best to encourage constructive collaboration. I apologize for any confusion that might have been caused.
It's clear that this issue is a necessary one to address, but should be done so carefully as it's a sensitive topic. I'm going to attempt to proceed with caution and with the assistance of anyone who's willing to provide feedback or help
I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority
I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority
That was my intention all along. For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary
I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority
That was my intention all along. For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary
this is untopical, but @SharkPool-SP I do think you should add a base64 option to the "save as" block of your recording extension as it's present in the other one but not yours.
I think it's fine to have collaboration. But in the case neither developer wants to collaborate, the better-written/older pr should take priority
That was my intention all along. For example, see #1040. Although it was older and technically had more priority, your extension had the same features and more. See the note I added upon closing for extra context if necessary
this is untopical, but @SharkPool-SP I do think you should add a base64 option to the "save as" block of your recording extension as it's present in the other one but not yours.
Not sure of the use in that. Plus base 64 is just the data uri without the start
Not sure of the use in that. Plus base 64 is just the data uri without the start
Base64, would, for example, allow users to plug into the "download data URL" block of the Files extension so they can record something in their project and download as they please at runtime
just a thought
Edit: forgot about your extension having the "download audio as" block, but still, there are a few vague uses I guess...
Not sure of the use in that. Plus base 64 is just the data uri without the start
Base64, would, for example, allow users to plug into the "download data URL" block of the Files extension so they can record something in their project and download as they please at runtime
just a thought
Edit: forgot about your extension having the "download audio as" block, but still, there are a few vague uses I guess...
'download data URL' requires a data.uri. Not plain base64
'download data URL' requires a data.uri. Not plain base64
I was aware of this, you could just concatenate it with the right prefix using the join block, but either way it's not a problem anymore since I forgot about your download block
@Brackets-Coder You might consider adding #756 as another example of a duplicate extension that has been successfully handled.
