I understand forking a project, but why would you wait until its done? Doesn't that defeat the purpose if you still rely on the origin?

Why not just work together?

I'm not worried about pixelfed forks because I have been open to feedback and almost every PR has been merged. Our enemy is not another fediverse developer, its the corporate silo'd social media. Its in everyones best interest to work together.

Follow

@dansup If you like what the fork does then you can always just merge back anything they do. If you dont then they can always just merge in future updates from you. Forks help each other thrive.

ยท ยท 0 ยท 1 ยท 1

@freemo A lot of the pixelfed features will be in the form of composer packages. Any one can contribute & use feature packages without having to fork! In a way, this makes forks irrelevant since every feature is optional.

@dansup You'd have to ask them what they hope to gain from a fork. Perhaps its just impatience? I think master on pixelfed is a month stale now, people might just be scared its stalled?

@freemo There is no master branch, or releases. It would be cool if they could contribute some code instead of just rebranding my code!

@dansup I was refering to the dansup/pixelfed repo's master branch.

They will wind up contributing whether its their intention or not. Just merge in any commits they make in their fork that you like.

@freemo That won't be necessary, they can just write their own feature packages that add new functionality or override existing code. It would be nice if they decide to contribute.

@dansup well that would be in their best interests usually. Lets hope when they see what you can do they will change their minds.

Where is the most recent code for us to contribute to?

@dansup @freemo Dan, I know you're trying to get it perfect, but maybe you should push some non-federation-critical code so the testers have something to test and don't get... testy. :P

I'll also say that putting the time in to write any PRs right now is hit-or-miss because I feel like there's a good chance of duplicating or conflicting with something you already did but just haven't pushed yet...

@trwnh @dansup I have to agree, keeping commits "secret" tends to be an open-source killer. branches are used to help keep it out of main code while still letting contributors work with (rather than against) the main contributor.

Sitting on the commits (for over a month now) tends to create a lot of fallout from OSS communities on projects where one person does most of the code.

Its your project of course, so do what makes you happy. But if the goal is to create contribution (and discourage forking) its usually a good idea to commit often.

@freemo @dansup One other thing to add that I think might be relevant: new features are nice and all, but there needs to be an MVP. If you keep adding new features and pushing release back month after month, then there's going to be too many changes at once, which makes it hard to test or to get feedback.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.