How can I be helpful to contributors?

[PullJosh]

@towerofnix, @HanClinto, I see that y'all are making progress and I really appreciate it. 😄 I got a bit burned out on Leopard for a while, but your enthusiasm is getting me excited about the project again.

Right now the Leopard repos are all listed under my name and published using my npm account, but it probably makes sense to change that. Others contribute just as much as I do.

If it would be useful, I could...

• Move the leopard, leopard-website, and sb-edit repos to a Github organization
• Create Github Actions for automatically publishing the master branches to npm (side note: could be good to rename master to main)

Would this be useful? Are there other things I should do? I want this to be everyone's project, not just mine.

[HanClinto]

Yes, both of those items seem great!

I think you've been absolutely wonderful! I've been looking for a good outlet for my kids to transition into Javascript or Python from Scratch, and Leopard is hands-down the cleanest transition I've found. You've done a stellar job on this, and I really love what you have here!

I guess I have the same question for you -- how can we be most helpful to the project? You've done a great job with this, and I'd love to help ease your burden if we can.

So yeah, like you said -- it feels like automating the deployment through Github actions and adding more people as reviewers of the repository would be a great place to start.

[PullJosh]

I guess I have the same question for you -- how can we be most helpful to the project?

The most helpful contribution is writing, testing, and publishing code that helps achieve these two goals:

• Ensure all Scratch projects run exactly the same when converted to Leopard
• Make sure the resulting JavaScript is clean, readable, and easy to edit

(Sometimes the goals are in tension, and then we have to discuss what the right behavior it is. But there are lots of obvious wins to be had, like your "if on edge, bounce" implementation. Those are great.)

So yeah, like you said -- it feels like automating the deployment through Github actions and adding more people as reviewers of the repository would be a great place to start.

Sounds good. I'll work on creating a Github org and auto-publishing packages to npm.

[towerofnix]

Thanks for your time and care getting this set up, @PullJosh!

I do have to mention that I don't have a lot of time outright available for projects—that is, active IRL work around 35 hours a week takes a certain toll (I'm only 19 ^_^), and I'm the manager for another project and do my best to give it time when it comes to working on things outside of my job.

So, I can't myself take an in-depth dive investigating solutions for the perfect, one-to-one implementation of "if on edge, bounce"... but I'm still very happy to review pulls, check for potential code optimizations and readability improvements, and help ensure we have good testing, account for edge cases, and design changes appropriately :) Basically, I'm glad to provide a second set of eyes on issues and pulls, even if I can't dig as deep as others may be able to!

A side note: Personally, I'd love to put more time and attention to sb-edit, the conversion layer between Scratch and JavaScript—and other languages or varying project representations. Naturally, it isn't the primary focus of Leopard as a whole, but I feel sb-edit has a lot of un-tapped potential, especially within the realm of manipulating the IR data directly. "Git for Scratch" (not just revisioning but also "merge requests" etc) seem theoretically fully doable, and I think the flow of parse -> process -> serialize that sb-edit provides could be a big help for that as well as other analysis or code modification projects!

There's also much potential for filling out the IO formats we've already begun to support - sb2 export, sb import, scratchblocks import (e.g. adding a button to "import scratchblocks into backpack" on the forums, like existed on the official Scratch site for a very short period) are all just waiting to be implemented :)

None of that is necessary work of course, and it probably doesn't make sense to go too deep with them until we at least have planned proofs of concept (other demonstrable ways to use sb-edit as a supporting library beyond Leopard), but they're ideas to think about down the line.

Back to Leopard - I definitely agree with PullJosh's summary of the two big goals of pull requests here. Scratch-Leopard compatibility and clean JavaScript are the two big focuses!

I think a cool long-term goal for Leopard, albeit definitely scope-expanding, would be a community site to share projects written with Leopard on. Keeping in mind the obvious security/sandboxing considerations of running arbitrary JavaScript, and the human time and work of moderation, I think it would be awesome for kids and developers of all ages and types to be able to share projects they made using Leopard with friends on a dedicated site. I'm thinking of a mix between Scratch and KhanAcademy's processing.js "sketchbooks"—probably similar to today's Snap! community site, but with room for commenting, some profile personalization, etc. Folk learning with Leopard should have the chance to share their experience and learn from others too :)

Codepen is pretty much the closest thing I know of to a "community" space where you can learn others' methods and practices when programming more focused, often visual projects, but I feel the community aspect is less focused there—it's moreso devs sharing with each other cool things they made, instead of specifically practicing and learning a new language. Since JavaScript has so many opportunities for cool programming techniques, and Leopard lends well to trying those out while still being familiar to Scratchers (and even others with minimal coding experience IMO), I think there's room for a more education- and learning-focused community built around this coding framework which is already very well functional today :)

Anyway, that's by no means a project I'm able to head/direct or even take a significant role in today, but I think it's another cool thing to think about if we're brainstorming potential paths for Leopard's future. Apologies if this is something of an info-rant without so much directly applicable today! Just thought I'd finally write down thoughts I've been having around Leopard over the last couple years ^_^

[PullJosh]

I do have to mention that I don't have a lot of time outright available for projects

That's completely okay. 😄 There is no pressure to contribute, ever, and real life comes first. But the contributions you make are much appreciated! An extra set of eyes goes a long way.

Personally, I'd love to put more time and attention to sb-edit, the conversion layer between Scratch and JavaScript

Yes! sb-edit has a ton of potential. The current sb-edit API is pretty bad, but if its I/O features were filled out more, the internal representation was cleaned up and simplified, and the I/O and processing steps were all made more convenient, it could be amazing.

I don't think I will ever have the desire to do that work myself, but the vision is clearly there for anyone who wants to pick it up. In the meantime, sb-edit will continue to be a means to an end for me. (A tool to make sb3 → Leopard conversion possible.)

I think a cool long-term goal for Leopard, albeit definitely scope-expanding, would be a community site to share projects written with Leopard on.

Now this is more up my alley. 😄 I completely agree that such a community doesn't really exist today to the extent that it should, and we are actually pretty well-positioned to take on that job.

I am curious when you think a good time to start work on something like this would be. Should more work be put into Leopard itself first? Or would it be nice to put up such a site soon?

I would be overjoyed to work on both building the site (including project sandboxing, building the code editor, etc) and also community moderation and such. But I have a bad habit of jumping into things quickly and then failing to see them through, and I don't want to make that mistake here.

Would love feedback from everyone on the right scope/timing for a community like this.

[micahlt]

I would be overjoyed to work on both building the site (including project sandboxing, building the code editor, etc) and also community moderation and such. But I have a bad habit of jumping into things quickly and then failing to see them through, and I don't want to make that mistake here.

Same here! Love what Leopard is doing, and I'd love to see a community site. I've built clients for social platforms before, so I would definitely be willing to put in some work on the frontend! Backend too, for that matter, as long as it's in Node.

Would love feedback from everyone on the right scope/timing for a community like this.

I think for a project as big as this, it would be practical to take a good amount of time to plan. We'd need to know what frontend and backend frameworks to use, where projects would be stored, a source of long-term funding, and how we would gain users. Slow and steady wins the race - no need to start a bunch of development without at the least having a roadmap 😁 There'd also have to be a decent amount of work put into branding and such.

I'm all in - coming from Scratch, I've wanted to see a lighthearted alternative that caters a bit more to more experienced users while maintaining the strong community aspects. I'm super interested to see where this goes!

Edit: from what I see, leopard-website is currently built with Next. Next would probably be a great option for a community site like this, where a lot of the basic database actions could be abstracted to serverless functions.

[PullJosh]

@micahlt I love everything you're saying.

I am branching out discussion around building a community into #116 so that this issue can remain focused on forming a solid path for open source contributors to Leopard (and sb-edit).

[PullJosh]

Okay... I created a new commit, c056bf9, with a Github Action to publish the leopard package to npm when a new release is created. I don't really know how to test this action other than to just use it and see what happens.

Dependabot is mad about a lot of old dev dependencies, so I might update those and use it as an excuse to give the action a test run.

[PullJosh]

The Github Action worked! 🎉

Now creating a new release in Github (which can be done from here) will cause the package to be published to npm automatically. Of course, this also requires updating version in package.json first. Each release should correspond to a bump in the version number.

I assume that contributors are able to create new releases. (@towerofnix or @adroitwhiz can you confirm?) If so, that's good because it means that I am no longer a bottleneck when updating the package.

Should I also set up this workflow for sb-edit?

[adroitwhiz]

Looks like I can create a release--I didn't try actually doing it but the form appears. I think setting this up for sb-edit would be a good idea.

[PullJosh]

How are y'all running and testing your changes to Leopard and sb-edit locally? Are you using the example-project/ folder in the Leopard repo? And how are you testing sb-edit? I feel like my system for this is quite bad. (Read: non-existent)

(cc @towerofnix @adroitwhiz)

[adroitwhiz]

I'm downloading converted projects into their own directories and just not committing them. There's https://github.com/towerofnix/sb-edit-playground which I've used in the past, but I haven't tried using it as of late. It might be worth transferring into this organization?

[towerofnix]

@adroitwhiz Oh hey, you remembered that repo before I did :)

I recently gave it some updates. It still works, but I faced some difficulties because sb-edit wasn't exposing to NPM the files needed for the TypeScript build. I don't know what the "proper" way of working with it locally would be, but apparently it's not whatever I was doing. In the end I removed "files": ["lib/**/*"] from sb-edit's package.json, but it felt like a bit of a hack.

(Edit: I'd be happy to move it over to leopard-js once we figure out the confusion with linking sb-edit, though! I already touched up the readme so it's basically good to go beyond that issue.)

@PullJosh I noticed you merged #129 before I'd reviewed it even though my review was specifically requested—in the future could you wait for all reviews to be 👍 before merging (at which point adroit could've merged, since they have member permissions as well)? Just so that third pair of eyes actually gets a chance to look and see :)

In this case it's no big deal as they're simple changes, but it's something to keep an eye out for in general, and is good PR etiquette (if the requested reviewer has been offline for a while or is unavailable they can always be removed from the reviewers list for that PR).

[PullJosh]

@PullJosh I noticed you merged #129 before I'd reviewed it even though my review was specifically requested

Ah, but I did not. 😉 adroitwhiz merged their own PR after my approval, presumably because it was a simple one.

But I'm glad you're keeping an eye on me. ;) I haven't done much open source, so it helps.

[towerofnix]

Oops, my bad ✨ Thanks for pointing that out for me! And totally.