Support schedule event for GitHub Actions

[ghostwriter]

Q	A
New Feature	yes

Description

• Add support for schedule
• part of Support schedule event for GitHub Actions laminas-ci-matrix-action#88

[ghostwriter]

closed, due to inactive maintainers.

• Asked to be nominated to help Maintainers. (ignored)

• Asked for input and feedback regarding issues and pull requests. (ignored)

• Contributors Time, Skills, and Unpaid Labor wasted.

• Discourage and drive away contributors.

Time to re-invent the wheel.

[Ocramius]

I'm sorry if your schedule does not match our IRL ones, but this is not the way to communicate with other volunteers.

In addition to that, we discussed this on slack: @boesing's work needs to take precedence here, as it is about mostly rewriting these components.

This is not the right attitude: it is detrimental to general morale, and doesn't help anybody at all, other than making yourself look like somebody that doesn't understand that shit happens outside your sphere of influence.

As much as I appreciate your help in getting loads of upgrades introduced in the various laminas repositories in the past few months, this sort of communication only drives people away, and erodes at mutual trust.

Personally, I'll probably refrain from actively helping you, if what comes back is a slap in the face telling me that my decade-long maintenance efforts, constrained by "needing to do stuff outside OSS", are "not enough": it's simply not worth my mental energy.

[ghostwriter]

@Ocramius

• Don’t let your emotions get the best of you and don't attempt to blame them on someone else.
• Your emotions are not my fault or my responsibility.
• I am not making you feel a certain way.
• You are choosing your feelings and how you respond to them.
• You can choose to respond in a calm, rational manner, and when you do, the anger dissipates.
• It’s when you respond in anger, you'll continue to be angry.

---

I'm sorry if your schedule does not match our IRL ones, but this is not the way to communicate with other volunteers.

I communicated via slack, and requested for someone to review two very small PRs, 1 Line Of Code and 4 Lines Of Code. (I was told to wait for laminas/laminas-ci-matrix-action#62)

In addition to that, we discussed this on slack: @boesing's work needs to take precedence here, as it is about mostly rewriting these components.

Correct, but both PRs are still incomplete/drafts, which will require more time to complete.

laminas/laminas-ci-matrix-action#62

laminas/laminas-ci-matrix-action#83

It became apparent that until those PRs are merged, my PRs will not be reviewed so I merged the PRs on my fork repo instead and closed this.

This is not the right attitude: it is detrimental to general morale, and doesn't help anybody at all, other than making yourself look like somebody that doesn't understand that shit happens outside your sphere of influence.

No, I simply decided to fork the Repos and merge my changes on the forks instead. Because the changes I was introducing were a total of 6 LOC, @boesing could include this in his work and I would not have to wait anymore because I have my forked repo

As much as I appreciate your help in getting loads of upgrades introduced in the various laminas repositories in the past few months.

I'm always happy to help, and that's never going to change.

this sort of communication only drives people away, and erodes at mutual trust.

I disagree, my intent was to close the PR and provide my (factual) reasoning. You choose to take it as a personal attack.

I respect your opinion that "this sort of communication only drives people away, and erodes at mutual trust"…. Why can't you respect my opinion that "Constantly having to request for review because PRs are ignored is very discouraging and would drive away contributors."

Personally, I'll probably refrain from actively helping you, if what comes back is a slap in the face telling me that my decade-long maintenance efforts, constrained by "needing to do stuff outside OSS", are "not enough": it's simply not worth my mental energy.

I don’t understand why you seem to think this is a personal attack.

I have always been respectful, and that's not going to change.

I have never forced you or anyone else to help me.

In fact, I have been helping others in slack, a lot more than I've asked questions.

Each time you've helped me, I've thanked you for taking the time out of your busy life to answer my question.

Going forward, I'll respect your wishes and I will refrain from asking you anything if that's what you want.

Thank you for all the contributions you've made, thank you for the few times you've answered my questions, and thank you for being open with me here.

---

An excerpt from “Best Practices for Reviewing Pull Requests in GitHub” - https://rewind.com/blog/best-practices-for-reviewing-pull-requests-in-github/

1. Respect People’s Time

A good code review process starts with respecting time. Ideally, you want to start reviewing the code within two hours after its first submission. This is mainly to appreciate the work of the person who submitted the PR.

For example, if one of your colleagues has asked you to review their work, they’ll probably wait
for your review for some minutes. If the review isn’t done quickly, they’ll start working on something else.

Your colleague will create a new feature branch and start writing code for a new task. If, after four hours, you review their first code and discover it’s faulty, your colleague will have to suspend what they’re doing now to make the changes. Context switches like that can be extremely time-consuming. Depending on how your colleague works best, it might take a lot for them to recover focus when coming back to the original task.

The situation gets even worse if you let days or weeks pass by without reviewing the code. At this time, your colleague has probably even forgotten what the code was all about. There will be time wasted while they catch up with the old code, and your colleague will be more prone to introducing errors since they haven’t worked on that feature in a while.

Always respect other people’s time and work, try to be the most timely reviewer you can be, and realize that those hours your peers are waiting for your review are worth a lot.

---

Needless to say, I harbor no ill will towards you or anyone. I will continue to contribute to laminas and mezzio, unless instructed otherwise. I have no intention of forcing my views or opinions on anyone.

In closing: If you have too much work on your plate, as an OSS Maintainer, pass the workload to other developers who are willing and able, like me, so you can focus on what matters to you (which should reduce your obligations to just reviewing & merging PRs). Leaving all of these Issues & PRs open is only adding to your workload and slowing down, if not halting, everyone's development process.

[Ocramius]

No, I simply decided to fork the Repos and merge my changes on the forks instead.

No, you decided to close after stating that we are "ignoring you" and that we are "wasting your time".

There is no need to drag this further: locking here for the sake of everyone that would otherwise have to deal with your abrasive communication style.