Upgrading flow of making issues and merging pull requests 2023

[yangwao]

Hey, welcome new 2023 (for those in Asia, soon!), and let's see how we can adjust some things we are working on in pull requests in issues and pull-requests; I've observed a few things meanwhile.

I'll try to be short and address those

Refine incentivization on priority issues p4,p5

I really get it you want to help move KodaDot faster to feel much better, especially during the wild time of doing a redesign.
Yes, every contribution counts, yet we have a range of priority issues for reasons to finish some things in some time window.

From p1 to p5, where

p1

• is urgent/broken app,

p2, p3

• we have designs ready/in progress, need your touch, and a higher chance for higher bounty delivering it fast, follow up issues to finish bigger milestone issues to be whole complete, something needs to be done just before release window, feature request being deployed in other repository--requires integration on nft-gallery

p4

• things are getting prepared to be integrated, yet doesn't encourage to pick up

p5

• we thought about it in room, backlogged, researching

I was in chat that we will roll some discount on rewards as bounties rewards should not be same for p4 vs p2 as we won't finish things for great user experience. Like there are few outstanding p2,p3 right now. I have in plan to sit one day and bit reorganize and refactor priorities based on what we should deliver this Q1.

Follow-up issues

I noticed that some time-to-merge are quite long.
It starts somewhere logging issue; someone takes it, creates contribution with their best intentions, raise pull-request, opens it for review, one-to-ten handshake peer-review between comments, and a series of approval like visual-ok, code-LGTM, works-for-me, paid out & merged.

Some things I believe it's hard to influence, but for those we can, I'd like to. Each extra time on PR, which is sort of stalled, adds extra time to resolve things and keep steady incremental updates.

Some PRs are good in size, some get complicated, and some are more complex beyond appetite delivered in the designed window.
I believe if we try to keep this time somewhere around 72 hours, we are good to go and can parallelize tasks among others, think about different kinds of specialization (if that something helps us out), faster knowledge sharing, fixing bugs it keeps us more steady and less burden on the person as I like to have a great distribution of tasks.

If it's about reward, I'm willing rather split tasks and get rewards between more people, for example, I always trying reward contribution by upper bound, until someone raises an objection or so, there is more people willing to engage and help you out.

Getting to the point that if you struggle with something, it's OK to make a follow-up issue. Even if you would like to follow up on that or someone else, it's GOOD for the project. As making issues is for us currently the most efficient way of the async way to communicate as we are spread across the world and timezones.

Lowering block time time is good and lowers odds for merge conflicts and someone waiting for someone else pull-request to be merged.

Atomic issues

This is something we started the previous year 2021 doing great, in 2022 it was oscillating and then it was going ups and down, now I see signs happening bit.

I know all of you are ambitious and willing to contribute, yet, keeping fast and slick on PRs is best. So, when we are making issues we try to nail down few things, if issue seems to you suspect it's gets bigger, it's OK to split it into multiple sub-issues, we have no problem with that, because with splitting you'll bring more talent into room. Even I know some people willing likely to focus on one component, I encourage you to share knowledge across codebase and I guess this year it will come to some sort of specialization to particular component, like CSS, Workers, GraphQL, Vue and so on as currently for someone entering our codebase, barrier is quite steep to contribute under 1h until they know codebase and I would like to change it somehow in better to welcome more contributors.

So the takeaway from this is don't try to raise one PR where you start merging another issue. Until that issues is highly contextual and could not be made between to. If so, best is to make PR where you state that other PR needs to be merged first.
I rather waste context switching than waiting for someone taking too big scope of task and others are waiting for them is not great approach I guess, however, I'll try to do best to somehow paralize issues which are non-blocking each other, there always be the case how it will happen, like with recent migrating our stuff from Pinata to CF, we've tried our best to resolve it in short time to get back you on track.

Assign bot

I've seen some arguing about limits and queue of issues. To be clear from the start it was always an experiment, it's a good rule fo thumb, and we wanted to avoid the wild west.
Hence, it's not crypto bull run anymore, we won't get a strong influx of developers until we start focusing on that.
Being said, I have few ideas how we can introduce another Assign Bot v2 with some upgrades, till then it's good to respect queue of issues, If you want to cross limit it's up to you, but thing is that if someone delivers it as assigned and you'll be making same PR, will choose one assigned, so you risking your proof of work being non-rewarded.
I guess we won't in this scenario soon as our contributors would need to be somewhere around 30 per month to have these conflicts often.

Communication

Since late October, I've frequently been travelling, conferences, events and calls; I haven't opened Discord probably since then and trying to narrow my communication here in issues and pull requests. However I appreciate all real-time comms; a lot of there is getting lost and even harder follow-up in our async fashion.

Even I was thinking of rolling Meta-Hours back internally in a private fashion.
We should probably get it back in fashion dev-office-hours, but only if someone shows interest in doing so.

I think we should probably redesign how some things are working, so feel free to raise suggestions.

Apart from that, we are thinking of bringing more devs over as KodaDot ecosystem would getting broader and goal would be have steady 20+ contributors EoY 2023, we are now at 13 https://github.com/kodadot/nft-gallery/pulse/monthly

• #4433

Payouts

Apart from traditional bounties, I'm looking for the best models to have a baseline on various tiers of contributors plus with bounties which are variable rewards based on your series of contributions which are still very warm welcome. Hopefully to dust settle, and will have more time to look at this as it's something I would like to be more advanced and share with other projects.

2000 pull-requests

Looking forward to the 1999th, 2000th and 2001st merged PR, I'll put an extra $100 for each PR out of my pocket to celebrate this small achievement for KodaDot, feel free to bump me when we get there :)

We are at 1916 merged PR, with the current 71 merged PRs per month, we will get there around the second week of February 2023.

Yay. 🎉

Fin

I'll try to follow up with everyone I promised in issues over Discord; I believe I have from your side DM if it's something, will answer it.
Best if you bump one more time, so it's among the top of my other DMs and refer to this if you want to chat:)