Fork

[karliss]

• name
• Readme
• docs
  • content
  • publish
• localization
• python package name
• config location
• outdated CI and other configs
• python package configs

[frmdstryr]

Would you be interested in taking over the whole inkcut project? I don't really have the time/interest anymore and it looks like you have a good understanding of the code.

[karliss]

@frmdstryr Sorry for late reply, was busy with the release for other Cutter software I am maintaining.

Wasn't going to bother you with with discussions about takeover and just let it happen organically assuming I keep the pace and if enough user feel like my fork provides sufficient additional value. But if you feel that making it more official could lift off some of the weight from your shoulders or provide smoother experience for end users I am opened to discussions.

If you want to discuss any details privately you can use the e-mail associated with my git commits.

In general there are two possibilities:
a) directly taking over the existing things
b) designate fork as more or less official successor

Approach a) means more seamless process for end users, but requires dealing with all the resources associated with inkcut name. Leaves the door open for you to more easily resume participating in development in case you recover interest (although not necessarily with the code base in state you prefer).

b) means more or less making final announcement that there isn't going to be further inkcut development anyone interested can take at alternatives like this fork (with whatever level of endorsement you choose), and marking the repository other resources as readonly. It's somewhat a middle ground between transferring the project completely and not doing anything letting there be a fork.
This will result slower migration process for end users, more time to buildup reputation.
Benefit is that puts lesser responsibility on both of us - less responsibility for you to decide whether I am sufficiently trustworthy, more freedom on my side to more radical initial reworks and potentially breaking changes during initial development. Less hassle with transferring control over various accounts associated with inkcut name. In this case the responsibility of decide whether they feel like I am trustworthy is up to each user.

It might sound a bit weird of talking myself as someone potentially shady. Stuff like xz project showed it's not complete paranoia either. And there have been plenty of stories with various browser plugin authors receiving offers to not only take over their plugins getting paid to do so. And in most cases it being quite clear that people making such offers don't have the best interest of end users in mind. Even if fork/successor project maintainers don't mean anything bad, I have seen some some share of fork maintainers which are less competent than what I feel comfortable with in general or compared to previous maintainer.