Does osTicket need a fork?

[martin-rueegg]

According to https://github.com/osTicket/osTicket/issues/3385 there seems some sort of stale state on the original project.

We have introduced osTicket recently and also like the slimness and speed of the application (having successfully used Request Tracker in previous contexts).

What we miss and would want to implement

• [ ] Employing composer
• [ ] Improving filters on incoming e-mails (e.g. mail headers)
• [ ] Merging tickets
• [ ] Linking tickets
• [ ] Having agents owing a ticket (Low priority)
• [ ] Having Admin-CC's (see RT)
• [ ] lightweight CRM

If there are other users that are committed to contribute to this project, we could start a fork. But likewise happy to provide to the original project.

[ArthurBorsboom]

Hi Martin,

Just as you, I am also happy to provide support to the original project. However there has not been any commit or issue response since July 2016.

There are so many developers offering their assistance, which is awesome. There are about 150 pull requests. That sounds like a good start to improve osTicket!

If we can find at least 3 developers (including myself), then I suggest we give it a go.

Ah, heck, I already have a fork. :)

https://github.com/ArthurBorsboom/osTicket

As a starter, we can merge a couple of pull requests per week of the original project into this tree and start looking for more people to join.

Wanna join?

[martin-rueegg]

Hi Arthur

Thanks for your comment and invite. Yes, I'm happy to join up. I would, however, prefer having the new fork on an organisational account, rather than on a personal one. Would you mind to join our repository?

I've seen, you've only 6 commits ahead of the original fork. So that should be quite easy to merge, apart from the change to the pear module, which I have already "outsourced" to a composer dependency.

[ArthurBorsboom]

Hi Martin,

Indeed it sounds better to use an organisational account.

I do like to understand better which organisation it will be forked to, what they stand for, etc. Maybe you can provide me some insights?

[ArthurBorsboom]

Hi Martin,

I have looked at Bristol Pounds. I fail to understand the relationship between Bristol Pounds and osTicket. Besides I have neither something against Bristol Pounds or an affiliation with it. :)

Wouldn't it be better if we create a new organisational account unrelated to somebody's business, only for the fork of osTicket?

[martin-rueegg]

Hi Arthur

Bristol Pound is a local currency scheme in Bristol, UK. Our affiliation with osTicket is solely that we use it and that we provide technical infrastructure and support for other currency schemes as well and as such are committed to open source software.

I'm happy to use an other organisational account, but would suggest that we fork from Bristol Pound as I have already merged your changes into our fork. And others.

We could use https://github.com/orgs/metaworx if you're happy with that. This is my own software developing company. We could also create a new organisation altogether, but maybe that's too early until it is clear whether or not Enhancesoft will be interested and/or willing to implement our changes once and if they're coming back alive.

If we want an own organisation, how about https://github.com/osTicketFork for the moment?

[ArthurBorsboom]

Hi Martin,

I like your suggestion for the temporary osTicketFork. Depending on the future, we could or merge it back to Enhancesoft or create a real new fork, like ehhhh freeTicket, or so. Forking your fork, sounds like a good idea, so let's do it.

Then the next steps could be

• implement each existing pull request from the original osTicket. I have found an article how to reuse existing pull requests: http://stackoverflow.com/questions/6022302/how-to-apply-unmerged-upstream-pull-requests-from-other-forks-into-my-fork. Inform each developer that their PR is implemented in the new fork, to revive the project and energize other developers. This can be done by commenting on their PR on the original osTicket site.
• search for more developers and give them access. A total of 5 sounds like a good number, to prevent dependency on 1 or 2 developers. So, since we are two, we only need 3 more.
• improve anything that bothers us (or other people) in daily usage.

How do you feel about this?

[martin-rueegg]

Ok,

• organisation created,
• project forked,
• you invited.

;-)

Regarding existing PR's: yes, I agree to have a look at them. But I also think we need QA in place as some PR seem to be very specific and or buggy.

Following the git-flow procedure that was in place in the original project, everything is implemented into the develop branch. I think, the develop branch should always be functional nevertheless. functionality could be tested in the production-test branch, for which I run a separate instance on my server.

As such, I we should be careful implementing all the PR's.

[ArthurBorsboom]

Yes, I agree.

I will follow on the suggested workflow. Does github provide a model for that?

[protich]

@martin-rueegg @ArthurBorsboom - a fork is always welcomed, I'll just ask them don't spam the official osTicket repo.

As for osTicket development status update, please see #3399