This is good - I previously used Buffalo https://gobuffalo.io/ at my startup, but eventually decided to move off it. Go doesn't seem like the kind of language that could support a framework like rails (it's safety takes away from the flexibility).
Would love to see how this turns out though! Great work
Hi! You can do that too. but Olvy already stores your user feedback and user requests to make the workflow easier. You also get a hosted changelog, a feedback management system and a lot more with it.
Since my university's curriculum was stuck in the 90s, I used Codecademy to teach myself JS, and Ruby. Thank you Zach, and everyone who has been part of the team!
We did something like this with our early users. Called the thing "The Builders Program"
For the medium, have one default you use but don't limit things to it. If one of your early users wants to use twitter to contact you and give you feedback, use that. We created a Discord server, had a group Twitter DM, used Email.
One thing you should do early on with these users is show them you are listening. Pick something they say and ship it as soon as you can. If they see you're listening, they'll be more active in sharing feedback.
In exchange for being part of the builders program we gave them lifetime free access to the product later on.
Yes, I think that valuing them through a named program is a great idea.
... and finding out what 'reward' they value the most, it might be different for different folk but free access to the product they supported is a great start.
This is a nice idea, and amazing execution on this. Really excited to see how this picks up.
But here are my concerns with the Git contributions to reward performance.
A company I interned at installed a Git history analysis tool, and used stats from that in 1:1s and performance reviews.
About a month after I joined, I had one such 1:1 with my manager. He was like, "Congratulations! You made 53% of all contributions to frontend last month. You're our star performer."
I wasn't. I was responsible for upgrading our frontend from React 15 to React 16. Most of the changes that happened were thanks to the Codemod, and a lot of find / replace magic.
A very good point. Solving the problem that you describe is one of the core challenges of LibreSelery. We combine multiple weights calculated based on different project data. Via the GitHub API we can even create weights based on projects activity like merging, code review, issue creation, etc...
By the accumulation of multiple weights, we try to avoid rewarding just one behavior. One of the most important metrics will be how much pull requests X have been solved based on the Y issues. We also have a minimum contribution limit that you can adjust for your project. Generally, all weights can be adjusted for each project. By making all payments transparent, everyone involved can see what the distribution looked like in the past. In principle, every company has metrics for the distribution of funds. Unfortunately, these are often very non-transparent. In contrast, we try to solve the whole thing by combining different transparent movement quantities.
You can find more information about this issue here:
Would love to see how this turns out though! Great work