GitHub PR discouraging delay

I spent a lot of time and created my first tutorial as a contribution to Arduino Docs 3 months ago and it seems that it has since been forgotten by the staff who promised to review and merge it with the main branch. Its quite disillusioning.

  • Is this the norm in the community or is there something wrong?
  • Has anyone had similar experiences?
  • How do I deal with this problem and how can it be avoided?

marqdevx commented on Jun 10

Sorry, I couldn't work on it yet.
I want just to make some small changes to fit our style guide, any major change.
I will jump on it ASAP

It seems that the problem is not on your side, so maybe you'll find another project to help, and maybe those responsible for other projects will have more agility in the implementation.

Don't get frustrated, sometimes it's normal to have delays or never implement our effort, but other times the effort is put to good use.

To help you must not expect anything in return, not even that the people or projects being helped manage to make good use of the help.

Take care, and have fun.

@rtek1000 I understand life happens, but I find it difficult to sympathize when a seemingly small task is delayed 3 times. I am more than willing to help fix the formatting, if I am given the tools and guidance to do so.

The team was very helpful and not only showed me my mistakes but also tutored me in a way. The last edit was made on the 23rd of May and we were waiting for the schematic pictures to be made. I checked in on the 10th of June and the team was understandably busy. I asked again 18 days ago and they were on vacation...

I was wondering if prolonged delays in addressing feedback in open source documentation is the norm even after being told otherwise by the administrators?

It is not at all unusual to experience long delays or rejection of contributions to open source projects in general.

Unfortunately, the creative process of making things tends to be seen as more exciting and rewarding than the maintenance work required to help others to complete their contributions.

I have submitted 7303 pull requests on GitHub. Of those, 1563 have not yet been merged. I have been waiting on some of them for 6.5 years.

So the answer to your question is "yes". I would say that everyone who has made a significant number of volunteer contributions to open source projects has experienced this.

Stay positive

Don't allow a single neglected PR, or even 1000 neglected PRs to derail you in your endeavors.

Learn

The second thing is to use it as an opportunity to improve. We can't go back in time, but we sure do go forward. Take some time to evaluate the situation and see if there is anything you can learn from it.

Move forward

If you are satisfied that your contribution is as good as it can be, there is no point in expending additional time and energy obsessing about it getting merged. That could be much better put to making more contributions to open source projects.

Sometimes forgetting about the PR is the best thing. You might think that once a pull request has sat for years without being merged, it is a lost cause, but I regularly get a notification that a PR I submitted long ago was finally merged. But make sure that you are getting notifications because it will sometimes happen that reviewers will request changes or clarifications and if you don't respond then it will be you preventing the contribution's acceptance.

If you are interested in contributing to Arduino's documentation specifically, but are burned out on GitHub - arduino/docs-content: Arduino documentation (docs.arduino.cc), there is a repository for the Arduino Language Reference content here:

The maintenance of that repository is surely no better, but perhaps a bit different at least.

Merging isn't everything

Something to keep in mind is that, if your work is of high quality, it has value even if it never gets merged. Open pull requests and forks often serve as valuable resources for other community members even when the project maintainer is neglecting it.

In this specific case, the work you did is not in any way dependent on the parent project. You can consider simply publishing the tutorial yourself to the platform of your choosing (e.g., GitHub, hackaday.io, Instructables, Arduino Project Hub). Then you have 100% control over its destiny.

The only way to avoid the situation is to refrain from contributing altogether. However, there are things you can do to increase your chances of getting a pull request merged.

Look before you leap

Evaluate the maintainership of a project before starting work on a contribution.

If you see that obviously valid pull requests have not been merged and a lot of issues have not been responded to, and there is no recent commit history, this is a sign that the project is not actively maintained. I will sometimes submit a "feeler PR" to a project for a valuable yet simple improvement that only takes me a few minutes to prepare. If that PR is merged in a timely fashion, it is a good sign that the more ambitious contributions will also be given proper attention.

Focus on mergeable PRs

A pull request for a noncontroversial, simple change is very easy to review and can be merged safely by any maintainer.

A controversial or very complex proposal is very difficult to review and might require high level approval. These are often the ones that sit unmerged.

It is best to always submit "atomic" pull requests, which are focused on one distinct change. A pull request that unnecessarily makes multiple distinct changes has a statistically higher likelihood of containing a "poison pill" that will delay or prevent acceptance even though other changes would have been accepted on their own.

Make reviews easy

A pull request that is difficult to understand or requires a lot of back and forth to resolve changes requested by reviewers is less likely to get merged.

Before submitting a PR, take a break and then carefully look it over with fresh eyes, providing the initial review for yourself.

Make sure the commit messages and pull request description are clear and provide all necessary information for someone to understand the purpose of your proposal.

If the project has automated validation systems (as is the case with the arduino/docs-content repository), run them either locally on your computer or else in your fork on GitHub. This way you know you will get a nice :white_check_mark: from the automated system that provides the initial triage instead of the dreaded :x:

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.