nostr:nprofile1qqsggm4l0xs23qfjwnkfwf6fqcs66s3lz637gaxhl4nwd2vtle8rnfqprfmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakszyrhwden5te0dehhxarj9ekxzmnyryc3g8 nostr:nprofile1qqsqxefne258ydmfgm2wfl02fsdqgs0d5wx29kweg9amxcqxew4t7kqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpz9mhxue69uhkummnw3ezumrpdejz72a3rzq nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z

Reply to this note

Please Login to reply.

Discussion

I personally see this as a personal responsibility problem. Public pull requests were a solution to patch contribution. There was one solution to rule them all, and that's open the general public to your project. This was not really how things were done, and I think it's fair to argue that many companies, especially on the larger side, managing OSS projects don't allow pull requests because regardless of AI PRs get to time consuming for serious maintainers who have an internal workflow.

I see this specifically as a problem for small maintainers who WANT to rely on public pull requests for public contributions. Which arguably few maintainers really want. They'd much rather have high effort patches sent to them in a way that fits their tools and workflow.

If GitHub allowed users to disable PRs I think we'd see FAR more projects with PRs turned off. I sure would.

Many projects move to private git solutions which requires complete vetting of contributors anyway.

> If I were a working on nostr+git I would consider orienting all my branding and value proposition at this problem

I think it's fair to say this assumes we agree the existing model of contribution is a standard to implement/compete with.

I don't want to build GitHub, or directly compete against it. You will lose for the foreseeable future.

I think it's normal and expected to want to protect the borders of your project. I think the borderless model works on a bell curve, and it highly depends on the product.