We are all deeply indebted to Stepan for all the pioneering work he did on embit and the Specter ecosystem. But it is also his prerogative to step away and spend his time however he prefers. If he wants to keep tabs on things and weigh in on occasion, amazing. If he wants to set this aside for months or years or indefinitely, all good. If he wants to return to being very involved and active, hurrah.
But the projects in active development that continue to rely on embit should have their own clear path as well.
Proposal
To my knowledge, embit is a foundational library used by:
- Krux
- SeedSigner
- Specter Desktop & Specter DIY
(if other projects are using it, please comment below)
I think each of these projects should have a representative as a maintainer for embit.
I don't think we need any sort of overly bureaucratic maintainer process here. This isn't about giving each project a vote, it's more about ensuring that any of us can pick up the mantle and continue extending embit if and when others drop off.
If a PR has been reviewed and has a reasonable number of ACKs, any of the maintainers who are well-versed in that area should feel comfortable merging it. I doubt that there would be any appetite for requiring coordination and counting maintainers' votes before a merge.
What constitutes "a reasonable number of ACKs"? Stepan has merged previous PRs either just on his own judgment or a single ACK. We are a tiny ecosystem. I think enforcing discipline to have at least one ACK is prudent. But I don't think we have the number of participants necessary to demand a higher bar. Each maintainer's judgment will remain our most valuable resource.
And I think we can trust our maintainers to exercise their judgment when there is a bigger change (e.g. a breaking change) and in those cases they should insist on broader awareness and consensus before merging. Having a representative from each project will make it easier to move forward on such major changes since a big part of the reps' role is to be the liaison between their project and embit.
Next steps
Discuss and debate. Projects nominate their maintainer reps.
I don't have a strong opinion if a project ends up with more than one maintainer; like I said above, this isn't about voting rights. I think all that matters is that each nominee is right for the job and interested and eager to take the lead.
If we come to consensus, presumably we need Stepan to add the new maintainers. It probably makes sense as a later TODO item for the maintainers to discuss gaining full admin privileges if they don't already have them.
We are all deeply indebted to Stepan for all the pioneering work he did on
embitand the Specter ecosystem. But it is also his prerogative to step away and spend his time however he prefers. If he wants to keep tabs on things and weigh in on occasion, amazing. If he wants to set this aside for months or years or indefinitely, all good. If he wants to return to being very involved and active, hurrah.But the projects in active development that continue to rely on
embitshould have their own clear path as well.Proposal
To my knowledge,
embitis a foundational library used by:(if other projects are using it, please comment below)
I think each of these projects should have a representative as a maintainer for
embit.I don't think we need any sort of overly bureaucratic maintainer process here. This isn't about giving each project a vote, it's more about ensuring that any of us can pick up the mantle and continue extending
embitif and when others drop off.If a PR has been reviewed and has a reasonable number of ACKs, any of the maintainers who are well-versed in that area should feel comfortable merging it. I doubt that there would be any appetite for requiring coordination and counting maintainers' votes before a merge.
What constitutes "a reasonable number of ACKs"? Stepan has merged previous PRs either just on his own judgment or a single ACK. We are a tiny ecosystem. I think enforcing discipline to have at least one ACK is prudent. But I don't think we have the number of participants necessary to demand a higher bar. Each maintainer's judgment will remain our most valuable resource.
And I think we can trust our maintainers to exercise their judgment when there is a bigger change (e.g. a breaking change) and in those cases they should insist on broader awareness and consensus before merging. Having a representative from each project will make it easier to move forward on such major changes since a big part of the reps' role is to be the liaison between their project and
embit.Next steps
Discuss and debate. Projects nominate their maintainer reps.
I don't have a strong opinion if a project ends up with more than one maintainer; like I said above, this isn't about voting rights. I think all that matters is that each nominee is right for the job and interested and eager to take the lead.
If we come to consensus, presumably we need Stepan to add the new maintainers. It probably makes sense as a later TODO item for the maintainers to discuss gaining full admin privileges if they don't already have them.