Have you tried enso, darklang, wasp, glamorous toolkit, mu, imp, simoji.pub, operon, cuttle, flowrunner, gadget, meemoo, MockMechanics, WhiteBox, MAudio, TypeCell, Ratio, natto.dev, kinopio? Why not? 😉 Maybe you didn't know you could? where to start? what to do? what kind of feedback to give? in which format? where to submit it? Here's an idea: Review Jam! A Week of Constructive Feedback and Conversations An opportunity to share and get real usage feedback on your project An opportunity to experience, review and get inspired by other projects Like a game jam but we try each other's projects Check the draft page and let me know what you think! http://marianoguerra.github.io/review-jam/

This is such a good idea. I love this. Suggestion: Add the text from your post here to the page, since it's a really good elevator pitch. Then the page becomes a canonical reference for this jam, and we can share it more broadly.

will do!

Projects propose a tool and a set of tasks

Where do the projects come from?

Very good idea! I'll DM you the github link of my project to replace the current one in the document

@Ivan Reese I would prefer to start wit FoC and FoC-related projects, I will contact the ones on the list and make some noise in adjacent communities

This sounds like an excellent idea, the critical problem for success being of course participation. I'll reserve some space in the last week of November! I suppose that exchanges between jammers and developers will simply happen on this Slack?

I think keeping it FoC centric will help, I would be happy with 3 projects 3 tasks and 9 reviews. Start small, iterate 🙂

@Mariano Guerra love this idea! definitely would participate. made me think of this bespokesynth.com first impression video i recently watched

🤩 Wonderful initiative! Would love to participate both in reviewing and exhibiting :)

Might also be nice if, as part of proposing a project, the tool authors also noted what kind of feedback they'd be most interested in receiving. Also, we should set a scope limit, something like 1 hour per project or something.

@Ivan Reese yes, I have to refine the "project/task submition 'form'" to maximize the "return of investment" for projects and reviewers, got some links with inspiration for related activities in other disciplines: • art: "Crit" https://web.archive.org/web/20200128204556/http://retnull.com/index.php?/texts/the-crit/ • writing: "Writers Workshops" https://dreamsongs.com/Files/WritersWorkshopTypeset.pdf

Sounds very cool! Besides feedback, I think it is a great way to get to know each other and learn more about the project in FoC. I would be happy to both receive feedback and review other projects. One thing I might not be against it "proposing features or changes", I find it useful to hear how others see the solution. But I guess that is under don't so people don't get too focused on describing their idea instead of idea they are reviewing? What is the next step -> creating a PR with our project details?

1 hour for whom, the project or the review?

1 hour to complete the project. Like, if the project is "Make a C/F converter" that sounds about perfect, assuming the tool setup process isn't hellish.

yes, I was thinking even less if possible

@Mariano Guerra that makes sense and I thought that was the reason you introduced it, but on the other hand, if we forbid suggesting changes/features/ideas, aren't we loosing a lot? It will feel like random people trying out our product, while we could learn possibly a lot from the review if they have some experience in the field or are potential user. I understand the situation with monologue, but instead of making it a "don't", which is very black and white, we could instead suggest reviewers to keep suggestions short / concise?

(This sounds great. I’ll do some reviews.) Should we have a channel for this? It might be surprising how many reviewers get stuck just trying to install the software, spend a long time figuring out basic interactions, etc. For that reason I think time limits are great and I’d recommend people start the stream/timer as soon as they take the first step towards using the software.

 what kind of feedback they’d be most interested in receiving.

Can also include what kind of feedback you’re not interested in receiving (so people don’t spend a long time digging into problems you’re already aware of--even if you really should be listening to them anyway 😁).

I was wondering if this initiative will be continued? There were only 2 projects added to the github issues I noticed

will give it a new push this week

Yes please. I messaged Mariano when it was posted that I was travelling, and then totally forgot about it. Now thinking about it again.

for now they are links to allow them to iterate on the tasks without asking me to update the page, at some point (soon) I can add them to the page

Ah that makes sense.

Just to check, I understood that there will be a dedicated couple of days or weekend for doing the reviews, kind of like a small event. Is that correct, or are we supposed to do the reviews as we go? I kind of liked the idea of dedicated time to focus on it, all of us.

there will be one week to do and submit the reviews, probably by the end of november

Yes, me too , but I am very happy with the pre-review that Kartik did. It certainly will help me to get more out of the reviews and preventing install-issues.

I like Wasp's idea of having the first task be to go over a tutorial. FYI, my current plan is to create a series of tasks with exponentially increasing complexity: 1. Read the Readme. 2. Here's a program, build and run it. 3. Here's a program, fill in the blanks to get it working. 10. Here's a working counter app. Add a button/hotkey to decrement the counter. You might want to consult _ in the docs. 20. Here's a working temperature converter. Turn it into a miles/km converter. 100. Build a simple CRUD app. You'll need the button widget from the counter and the input widget from the temperature converter. This way the tutorial spans the first few tasks, and then the reader is encouraged to spread their wings. I'm curious what else people are planning. One idea: plan identical tasks for two projects. That might help reviewers context-switch. I also have it on my todo list to take inspiration from the exercises (tabs) at https://www.hedycode.com/hedy

"See how far you can go" is an interesting challenge

Thanks @Kartik Agaram! Tutorial is a part of what we recognized so far as a happy path for the newcomers. First they install Wasp, then they create a new dummy app with it (takes just one command to generate it), then they run it and see some results, and then they continue to tutorial where we guide them step by step in building a Todo app, where each chapter introduces a new feature / complexity to the app. As you said, it is about increasing complexity with every step. What is important is that every step ends with a victory, a feeling of success. You list of tasks sounds good! Have you considered maybe keeping them all in the same context? Instead of each step introducing a new kind of app, maybe it could be just a single app that they are improving on in each step? To preserve the context and reduce friction? And they feel like they are building this thing, instead of throw-away exercises?

Just a brief update: I've been working on my task list here: https://github.com/akkartik/mu/blob/main/tutorial/index.md. Still lots to add from the outline at https://gist.github.com/akkartik/834531127fb0f12cd139c125edc62ac6, but I think I'm going to focus on just the first task list there.