Why has PW so many open/umanaged pull requests?

[Alpine418]

Hi guys,

I recently visited GitHub, researched the source code of ProcessWire and created a pull request for a small typo fix.

But what I saw did not make me really happy. ProcessWire has a huge list of mostly small but usefull pull requests which are all open.

https://github.com/processwire/processwire/pulls?page=1&q=is%3Apr+is%3Aopen

Why is this? If they are not usefull, why are the pull requests not getting closed?

Best regards,
rjgamer

[bernhard]

The sad truth is that ryan seems to ignore them ? I've mentioned that several times but all of my questions where handled like pull requests: ignored. Maybe @netcarver can tell us something more about that topic, as he is taking care about the pw-issues repo. Thx for that btw! ? 

Ryan has already pulled in some PRs - it just takes a little time sometimes but he has stated that he is happy to get contributions!

[netcarver]

Hi @bernhard, @rjgamer

Thanks for the comments - I share some of the frustration you are voicing - but I'm only able to handle issues on the processwire-issues and processwire-requests repos. I don't have admin rights on the main processwire code repo so I can't take any action on PRs, even if I wanted to.

Perhaps we could invite @horst  to also comment here as he is the only member of the community who I feel has been successful at having bulk code submissions adopted into Processwire.

[netcarver]

If your PR addresses an issue, rather than a feature, then one approach to the logjam would be to post your Pull Request on processwire/proceswire as normal, but then to add a new issue on processwire-issues that links to it. I can then tag your issue as "contains a fix". Hopefully this will put it on Ryan's radar.

I've done one example of how this might work: https://github.com/processwire/processwire-issues/issues/1016

Similarly, if you create a PR for a feature, then there is nothing preventing it being referenced by a new issue on processwire-requests.

I really wish this were more frictionless, but it's all I can think of at the moment.

[horst]

3 hours ago, bernhard said:

The sad truth is

After looking to it a second time, one may come to be able to see the not so sad truth, that is: With ProcessWire we have an opensource project on a very high level in regards of code base, stability & homogenity and much much more along those lines. AND all of of this is directly related to Ryan's decision to *work through all pullrequests* himself to deeply understand, modify, and adapt the code, so that he himself is ALWAYS & IMMEDIATELY able to fix bugs resulting from those code changes. (Even after years, when maybe some people who have sent PRs have left the project again and are no longer reachable.)

This has a lot of advantages! And it has, (as everything has), some cons. One of them is, that he is something like a OneManCodingArmy :-), but he is only *one* man. And I don't want him to waste his time to read through every github issue, plus every github pullrequest AND ANSWER TO EVERY ONE of them, in order to explain "why he doesn't want to do it that way, or that he doesn't have time now to do it, or that it could produce a lot of side effects, or, or, or". And one of my fantasies is that he might already be unhappy about not having the times to be carefree active here in the forums, as it was possible for him until about 4-5 years ago. It might feel ungrateful for him to read such a post. This, as a result of his disciplined behaviour, to advance the project as far and effectively as possible. Every week, or almost every day.
(( @ryan Did you imagine or wish this when you turned your code into an open source project in 2010? I'm just kidding! But it may sometimes be tiring to be confronted with the same thing over and over again, when the answers have already been given many times and the internet supposedly doesn't forget anything. But when people "don't have time" to do a little research first, or try to look at it from a different angle before, but (in the worst case without any impulse control) always bring up the same things again. Pffhhhh, for my well-being that would be nothing. ? I want you to have time and energy to work in your own flow & rhythm on *your* ProcessWire. Your ProcessWire, that you gifted to us. ? ))

 

@bernhard The truth is, (not the sad truth, not the happy truth, just the truth): it's one of two possible choices that he took 10 years ago. With all the pros and cons. In my opinion, every member of the community should respect that and never forget it. Because all that we have learned to love and appreciate about ProcessWire, all that has enabled us (even in early days, when we may not have had much code experiences) to write our own modules, is the result of that decision and I wouldn't want to miss it.

The alternative would be to abandon this course and (quality) control. But all the people I've spoken to in the past, all of whom have more than 15+ or 20+ years of experience in the software business and open source sector, have consistently told me: "Be glad that it is this way. There were so many projects that started that way, but opened up and broke 1 or 2 years later."

 

And about @netcarver question: I have contributed a lot of stuff in regard of image handling in PW. But it seems that less then 5% of it is reflected in githubs contributors list. The most things, where Ryan included my PRs as is, we have had conversations and colaborations about and on it on github or private via PM or email, until the code was accepted by him (in regard to his principles, anounced above). Aaand, it could be, that it also has something to do with the fact that he not only made the experience that I am still approachable after 6 years when it comes to issues, decisions or questions, but that I also not only understood his decision, but also respect it. Even if it has a negative effect on me in some areas. (But that's also just a fantasy of mine, with no claim to truth.) ?

 

[bernhard]

I get your point @horst and what you describe is perfectly fine, but IMHO it wouldn't be a sad truth if it was communicated that way...

Quote

Please do not post any pull requests to the ProcessWire project. Use the PW-issues for reporting bugs and PW-requests for reporting feature requests instead, so that Ryan can provide best level of support and quality control.

--> "not-sad-truth" ? 

Quote

Please post your contributions to the project here.

--> invest time for PRs --> PRs are ignored --> sad truth ? 

There are really small PRs that could be easily implemented within no time (eg https://github.com/processwire/processwire/pull/138/commits ). I understand, that checking all PRs can cost a lot of time, but that could be done by someone else just like @netcarver does it for the issues repo. Someone could tag simple fixes and ryan could then just work through PRs having some kind of label.

[netcarver]

6 minutes ago, bernhard said:

invest time for PRs --> PRs are ignored --> sad truth ? 

While the PR list has been static for a long time, some of the PRs have been addressed and can actually be closed now - just not by me (eg see this one.) However, because the code repo is separated from the issues and requests repo, this makes the linkage a little diffucult to follow at times and some PRs that have been acted on are probably still open. If anyone spots PRs in this state, please ping the original author (or Ryan) on Github asking them to close the PR.

I do see your p.o.v in that many of the PRs have not seen any action, and this may discourage potential contributors from posting any more PRs.

4 minutes ago, bernhard said:

There are really small PRs that could be easily implemented within no time (eg https://github.com/processwire/processwire/pull/138/commits ). I understand, that checking all PRs can cost a lot of time, but that could be done by someone else just like @netcarver does it for the issues repo. Someone could tag simple fixes and ryan could then just work through PRs having some kind of label.

Like this?..

2 hours ago, netcarver said:

If your PR addresses an issue, rather than a feature, then one approach to the logjam would be to post your Pull Request on processwire/proceswire as normal, but then to add a new issue on processwire-issues that links to it. I can then tag your issue as "contains a fix". Hopefully this will put it on Ryan's radar.

 

[bernhard]

7 minutes ago, netcarver said:

Like this?..

Yes, like this. But at a prominent spot. At the moment we have this in the contributing guidelines (that are only shown on the issues tab btw):

Quote

Pull Requests (PRs)

• Pull requests should be submitted to the processwire repository, and based on the dev branch.

• Before submitting a PR, read the Contributor License Agreement (CLA) at https://processwire.com/about/license/cla/ and indicate your agreement (electronic signature) by completing the form at the bottom of the page.

• Please note that we generally avoid adding features that aren't going to be used by at least 30% of the ProcessWire audience. Often new features can be better accommodated with modules. When in doubt, submit a feature request first to propose what you'd like to add, and indicate that you are able to submit a PR for it.

• See the ProcessWire Coding Style Guide before submitting a PR. While it's not required that you adhere to the style guide, it does increase the odds that we may be able to directly merge your PR.

• Please only submit code that you feel confident is stable and you have thoroughly tested. Verbose code comments are also appreciated when possible.

• In many cases we do not directly merge pull requests with our established workflow. If we do not directly merge the pull request, but do add the proposed features/changes, you will still be fully credited directly in the commit message and often times in our blog.

There's no hint at all on the PR tab:

[Robin S]

6 hours ago, bernhard said:

what you describe is perfectly fine, but IMHO it wouldn't be a sad truth if it was communicated that way

I think this is the crux of it - it's mostly a communication issue. It's not surprising that people come to PW with an experience of seeing how some other open-source GitHub-hosted projects are managed and expect that it's the same for PW. Many projects encourage the user base to submit pull requests. However, PW is not one of those projects and this probably needs to be communicated more clearly somewhere.

Open-source is not one thing but many things depending on the project and those who manage it. My impression is that PW is open-source in the sense of "a very smart person made this software and you can use it for free and also modify it to suit your needs". But it's not open-source in the sense of "hey everybody, let's collaborate on writing code for this software".

There will be pros and cons to the different approaches to managing an open-source project, but all things considered I think most would agree that the formula Ryan is following has proven very successful to date.

[arjen]

10 hours ago, Robin S said:

I think this is the crux of it - it's mostly a communication issue.

I can't agree more. Of course there is a logical explanation behind the current situation - there mostly always is. But the open PR's could easily be interpret as a "stale" project. Of course this is not the case as ProcessWire is one of the most worked on CMS. By mostly one guy (not to undercut the other module contributors, lots of love there). Which on itself is pretty amazing. Therefore this is true too:

18 hours ago, horst said:

Be glad that it is this way. There were so many projects that started that way, but opened up and broke 1 or 2 years later."

ProcessWire finds itself positioned in a very difficult spot. To clients this isn't very much a problem, since I always find it to be reason of the professional to sell its tools to their client. But selling the CMS to other developers/companies is a lot more difficult. There are quite a few pain points such as the open PR's, the first impressions of the master branch (last commit: 21 dec 2018), the already dated design of the website, the lack of github stars. When I Google for ProcessWire the repository of Ryan is even on a higher position than the current repository (last commit: 7 Oct 2016). The notice on top isn't very clear. 

These are not important to me*, but first impressions do matter.

[off-topic]We should really highlight these strong points: the really great custom field CMS, the speed of development (example: the .wepb support), the great (paid) modules, the great community, second-to-none multilingual support, the great documentation and the greatly written blogs too! Ryan has his way with words.[/off-topic]

* I had to look twice myself ?

[Boost]

So, what is the point of open source if community contributions are ignored? Marketing? Being open source entails more than just allowing others to view your code; it also involves building a community around the project to contribute to it and not only to give support.

[pwired]

Processwire would not have become this unique amazing cms/cmf if it was not for Ryan giving the direction how Processwire has developed.
Having said that, nothing stops you to fork Processwire and build any opensource community around it you want.

[bernhard]

I've edited my statement from 2019. Ryan has already pulled in several contributions and said he is happy to add others. So I think while it does not happen very often (which has the benefits that @pwired mentioned) it is not true (any more?) that PRs are ignored ? 

[desbest]

Two words: quality control

Too many cooks spoil the broth

20 chefs all working on the same soup, makes a crappy soup

Someone has to to be the ringleader to perform quality control on every pull request, rather than to just add it in because "it works and a net positive feature set"

Unless you want it to be like other open source projects, where anything and everything gets added in, just because it works and provides a net positive for the feature set, like [[[----insert other CMS here ----]]]  ??‍♀️

[Boost]

Understood now. Thanks.