Sure! I'm already under contract half time, and I work on my own company for like two full time, so I can't be a big contributor, but I contribute here and ther

Sure! I'm already under contract half time, and I work on my own company for like two full time, so I can't be a big contributor, but I contribute here and there to open source projects, so I can look around from time to time. > For example, how would you break the re-write into parts, and prioritize? I would probably do it component per component, factoring out complexity one method at a time. I avoid "big rewrites", aka v2 or whatever, because I've seen too many startups doing that to disastrous consequences (typically: a whole dev team not releasing anything for like a year, and a "new" app that is at the end not better than the previous one). Not really a surprise: v1s are iterated on and always keep track of reality, by releasing often - which v2s never do, they just try to bring everything at once. > How might we organize tickets for people to help? I guess people at Gitlab have way better ideas than me, given how successful they've been at that :) I see you already have a "help wanted" section, that's probably the most important, so contributors can quickly spot low hanging fruits and help a bit.