search

octobercms / october

Self-hosted CMS platform based on the Laravel PHP Framework.
https://octobercms.com/
Other
11.03k stars 2.21k forks source link

Ways to Speed up October CMS Releases #3913

Closed ghost closed 5 years ago

ghost commented 6 years ago

Intro

Before I write this issue, I hope I won't annoy the admins and creators of this wonderful project and I truly hope October CMS will continue to grow and get better.

The Issue

The problem with October CMS is that releases are coming out very slowly and people have written Pull Requests that seem to just sit there for years! It must be very annoying for people to have spent time and have written the code for the PR and their PR just to sit there for years. Some PR's have been sitting there since 2015 for example.

Another slow process is the issues, for example, I have filled an issue on Nov 2017 and even now I am still waiting for the Pull Request to go through. I need that PR to go through so that I can fixing other issues that my clients have been complaining about October CMS for over one and a half years now! It actually creates a bad image for October CMS having these prolonged issues that seem to never get fixed and sorted out.

The Process (from what I have witnessed)

October CMS has grown from a small project into a large project - yet the same structure seems to still be going on. Only now in 2018, Luke Towers adds labels and replies to the issues and then asks people to help him, by creating a Pull Request and when the Pull Request has been done. There are some extra moderators checking the Pull Requests and then the Pull Request gets sent to DaftsPunk to get Checked and can sit in his "To Do List" for a long time.

This process I can understand when October was a small project, but now this is a large project and I think the authors and creators need to update their process structure to speed things up!

This exact same process structure is what the AMP-HTML Project used and everything went through a single person called Malte Ubl. When they were doing that, issues were slow to get processed, taking several days and the PR's took a long time to process some taking several years. Now they have updated their process and I can raise an issue over there and the PR will get done within 3 hours to 3 days and then there is a 2-week waiting time to update the AMP-HTML version release.

With October CMS I would be happy if the release time was 4 weeks (1 month) but it seems much slower!

The Solution (I suggest) an Open Governance Model

First of all, I strongly believe this project belongs to Alexey Bobkov, Samuel Georges and Luke Towers. I fully understand they should get paid and make money through this project. But this issue I want to raise is not about that. It's about trying to speed up the process of raising issues, creating Pull Requests and Releasing CMS Updates. Because I personally need to fix several issues that are affecting my websites and annoying my clients due to taking so long to resolve!

With regards to the AMP-HTML project they moved their processing structure over to an "open governance model" you can find more details here: https://amphtml.wordpress.com/2018/09/18/governance/

And a youtube video detailing their open governance model here: https://www.youtube.com/watch?v=UKTJRrmDIh0

The reason I keep mentioning the AMP-HTML Project is that both that project and October CMS have the exact same structure and I believe October CMS should also change it's processing structure and move towards an open governance model. Thus speeding everything up and putting less work on just a few people.

Then hopefully we can start to get October CMS Updates released quicker, PR's processed faster and Issues dealt with easier and not expect Luke to process every issue, because he is not a robot (although at times I think the guy must be).

GinoPane commented 5 years ago

@ayumihamsaki Bravo! You've described everybody's pain 😄

amjadniazi48 commented 5 years ago

i think octobercms new bulid release should be announced on the website, like build 443 and then buid 446 along with change log.

LukeTowers commented 5 years ago

@amjadniazi48 change log is available here: https://github.com/octoberrain/meta/tree/master/release-notes

LukeTowers commented 5 years ago

Closing as it has been over a month since any activity on this occurred and we are trying to figure out what issues are still relevant. If this is still something that you would like to see through to fruition please respond and we can get the ball rolling.

ghost commented 5 years ago

@LukeTowers I dont want to sound rude, but I got 30 PR's just sitting waiting for testing and to have Reviewers and/or Assignees. It seems like people are trying to avoid PR's with more than 5 files been edited. Anyway to deal with the issue of processing these pr's and finding testers.

w20k commented 5 years ago

@ayumihamsaki you're not exactly correct. I haven't had time to deal with those, but so far half (or more, haven't posted a comment) of deprecated js functions I've reviewed. I'm just waiting for the next release to proceed with your changes 459.

ghost commented 5 years ago

@w20k You miss my point, it's seems like you are the one doing 80%+ of the testing! I'm suggesting to Luke to try and find more testers to help you out.

w20k commented 5 years ago

@ayumihamsaki it's easy only on paper (in theory). I'm not just testing, and it's easier for me to deal with JS/CSS stuff, but trying to understand the idea behind PR, dig in into the code (when needed), test and follow up with an optimization suggestions if needed. Testing is simple in the nutshell ;)

ghost commented 5 years ago

@w20k yah I agree with you, I just think testing is not straight forward to October CMS. Things are not isolated correctly. For example, the latest pr I did the blue sidebar in the cms page and the blue sidebar in a plugin web page uses the exact same class without any isolation container. Though the code is exactly the same the enviroment is not the same. The correct method would be to add the container class to the class for example:

CMS page

#cms-page .sidebar

Plugin pages

#form .sidebar

but instead we just got the setup as:

.sidebar

Testing in October is not always straight forward there are always hidden issues.

So what I'm saying is that the testing maybe easy but takes up a lot of time!

If there were more testers, then the jobs could be split up to more people.

In a perfect world I think October would be turbo charged with the following:

5-6 testers, split between php/css/html/yaml and javascript/css/html/yaml.

I think this would speed everything up and make everyone's life easier.

Maybe also remove the testing label and add some testing priority labels e.g.

For example, I have a pr https://github.com/octobercms/october/pull/4501 that needs to be merged before I can begin work on the checkbox and checkbox lists. So I would want that to have a high priority. Whereas this pr https://github.com/octobercms/october/pull/4503 is not connected to anything and so can have a low priority.

Lastly, the jQuery pr https://github.com/octobercms/october/pull/4461 is quite important pr but needs to be held back as per luke's comment, so it should have a testing medium priority.

Hopefully, that all makes sense.

bennothommo commented 5 years ago

@ayumihamsaki If we had more testers, then we could assign priorities for testing. I'm fairly sure the intention of the "Testing Needed" label was to encourage people looking to contribute to the project to test - it was one of the things I did before I became a maintainer.

If you wanted to assist with rallying people to help test, the project would definitely benefit from it, and it would very likely speed up any new functionality and changes being reviewed and merged.

ghost commented 5 years ago

@bennothommo What you said is exactly what I'm thinking. I wish Luke or Daftspunk would convey that message to the October community and even post that on the October facebook web page.

It would be amazing to have all the pr's tested within a 6 month time frame. Instead of what's happening right now with some PR's sitting there for over 15 months labelled 'testing' still.

LukeTowers commented 5 years ago

@ayumihamsaki another thing that can help make sure your PRs go through quickly is working on making them easier to understand. A lot of the content may seem obvious to you but try to frame it from the point of view from someone who doesn't currently think there's a problem and doesn't know about any potential solutions to that problem. Currently there's a significant number of PRs that come from you, which is great, but it seems like there's always some overlap between them and each one generally ends up having merge conflicts. Having all of these separate PRs makes it extremely difficult and time consuming to test any of them because I now have to look at all of them and spend a significant amount of time understanding all of the proposed changes before I can even being making suggestions for improvements that will lead to them being merged.

Since no one works on October full time (we're all volunteer), that means that complex PRs that are broken into many separate PRs with difficult to understand changes will not be very high on our priority list to deal with on a daily basis because it requires too much of a single time investment to be able to sit down and review it all at once. I mostly operate by having maybe an hour or two at a time to deal with GitHub issues and since there's so much to deal with I have to prioritize how I spend my time. If I can deal with and solve 12 different issues / PRs in that hour but can't fully understand all of yours in the same amount of time then I'm going to prioritize those 12. I feel like right now it would take a solid 8 hours for me to sit down and just focus on all of your PRs.

Now, I value your contributions and I will get to committing that time to review them just as you've committed your time to make them in the first place, but I have to prioritize other issues that I can deal with quicker first. Right now my priorities are finalizing Build 458 (I have over 100 notifications that I have to review) and also working on my own client work that pays the bills. Once 458 is finalized I can try to set aside some time to review your work.

ghost commented 5 years ago

@LukeTowers

Sorry about all the extra work, you told me to break down the pr's into spearate things to make it easier for testing.

Yes there are quite a few PR's with 10 - 20 file changes, had no choice because I needed to update October CMS code as it's quite old.

Now that you have given me a https://github.com/octobercms/october/projects/9

I can just work on that stuff and then it can be reviewer whenever.

The trouble I'm finding with October is when I fix one thing, I discover another issue with the cms. Hence the overlaps.

I'm up for doing anything that makes the admins' lives easier with the PR's I create.

I just want to update October with a few things I feel are quite important.

My list was basically:

  1. Add the dragbar feature
  2. Add the stretch and grow feature
  3. Add more columns to the backend
  4. Add keyboard navigation
  5. Fix the dashboard area
  6. Fix the top navigation
  7. Fix the sidebar
  8. Fix the settings sidebar
  9. Increase the performance by splitting the js code into sync and async

I know there's no rush to get these things done.

It's more of a side project of mine to help out October CMS team - as I got just over 300 websites running on this CMS.

LukeTowers commented 5 years ago

@ayumihamsaki that's fine to have it broken down into those goals and have a PR for each goal. However for stuff like the jQuery upgrade there's currently ~6 open PRs for that when it could just be one, and for all the other stuff where you have an issue and a PR I would prefer that there was just a single PR providing information on the issue and the fix at the same time. Issues should be separate from PRs under the following conditions (general guideline, list isn't exhaustive right now)

  1. Reporter doesn't know how to fix the issue / doesn't intend to fix the issue
  2. Reporter doesn't know if the maintainer sees it as an issue and doesn't want to invest the time in fixing it if they don't want to merge it (this only applies to new contributors unfamiliar with other channels however; I would prefer that if you're wanting to know if we consider something an issue or not you reach out on Slack instead of opening an issue)
  3. New functionality will be added after a period of discussion with the community.
ghost commented 5 years ago

@LukeTowers I feel your points should be added to this file: https://github.com/octobercms/october/blob/develop/.github/CONTRIBUTING.md

LukeTowers commented 5 years ago

@ayumihamsaki done: https://github.com/octobercms/october/commit/a9072b0d97d96d718667d3b3d6c55375ab2d8dd8

ghost commented 5 years ago

@LukeTowers Styled version: https://github.com/octobercms/october/wiki/Contributing-to-OctoberCMS

p.s. I dumped the images in this repo: https://github.com/ayumihamsaki/october-images

Wasn't sure where to put them?

ghost commented 5 years ago

@LukeTowers @bennothommo

I wanted to make a suggestion, it seems like most of the big pr's are to do with enhancements etc and you said all the admins do this part-time.

I was thinking would it be a good idea to add a pinned thing to this repo asking for testers to test the pr's with enhancements.

They are not really technical, they are just big and the time spent to test them would be on finding conflicting things with other features, such as forms and styling etc.

I just think if people can help reduce your work loads then it should help speed up things and make your lives easier.

w20k commented 5 years ago

@ayumihamsaki it probably would be a good option, but you can't pin PR's as far as I know.

ghost commented 5 years ago

@w20k hehe no, I just mean put it in the pinned issues, https://help.github.com/en/articles/pinning-an-issue-to-your-repository

ghost commented 5 years ago

By the way I think there are two types of testers needed.

  1. Non-techincal testers, many people say they are new or not very strong coders etc. these people can still test feature enhancement pull requests - just by testing the pull request to see if there are any bugs or conflicts in the user-interface.

  2. Techical testers, these are pull requests, that are more to do with bugs and pure lavarel issues, things that need testing with regards to the core code more than the user interface.

(that's what I've noticed while spending some time in this repo)