TL;DR. Trim it down to the core question; the backstory doesn't help. You can't just schedule a meeting; you need to tell other people what the meeting is about, get them to agree that the meeting is worth their time, get them to agree that the time and place are reasonable... And even then conflicts may come up that require rescheduling. Sounds like you didn't get firm agreement before the meeting and there was a conflict. It happens. Determine what you did wrong (ask the folks involved, if you aren't sure), learn from it, and stop panicking.

Give this a read: stackoverflow.blog/2023/05/10/…

@GammaGames, thanks for the link. The second paragraph of the article rings so true.

You say you're in the information gathering stage; but you have a concrete PR you want them to comment on. Which is is? Because those are polar opposites.

@Flater, In my previous company, PRs were used to gather information on an approach so I don’t consider them polar opposites. That said, I do think the PR was a mistake because it made my colleagues think I wanted to do something now.

@mobileDev14 A pull request is a request to have your changes merged into the rest of the code. It is a statement of "I believe this task is complete, please confirm", not a question of "please help me understand this". I understand that you may have worked with them differently but now you're in Rome you have to do as the Romans do; and you have to consider what your actions look like to the Romans. Your actions are speaking a very different language from what you are claiming you're doing in your question.

@Flater, thanks for drawing out the point about the pull request. I think that was the nail in the coffin, meaning it really closed people’s minds to my efforts. As a next step, I’m definitely going to close the pr, but I thought about adding a message to the effect of: “I realize this pr was premature to say the least.” But, perhaps closing it and saying nothing is the wiser course. Any thoughts?

Apology is not particularly useful in PRs. And apology generally is not needed in this case; just try to learn from it. We all make mistakes as newcomers, and thinking we can improve the build process without getting buy-in is a common one. First understand why it is how it is, then understand how much work it would take to change, then talk to your manager about whether that work is worth doing and what its priority is relative to the umpteen other things they need done. To do this through your ticketing/code-management system, you would open an Issue, not a Pull Request.

Are you telling us that your pull request didn't contain code/documentation changes and that it's just a messaging channel for you?

One observation - developers in my company do sometimes use pull requests for demonstrating prototype code, looking for feedback. But in such a situation, I would expect the PR to be clearly identified as such, usually with a description including the words "DO NOT MERGE"...

@GammaGames, the link you shared was very on point to this question. I realize that some frown upon answers that are just links, but I would suggest making your comment an answer to increase its visibility. I would upvote it for sure.

@StephanBranczyk, my PR did contain those things but I was trying (unsuccessfully!) to follow the approach of Simon Geard.

5 weeks is way too soon to be taking on company processes (unless you were literally hired for that task) and comes off a bit arrogant because surely the employees that have been there longer already know about the deficiencies in their processes, and clearly things already are being done.

@SimonGeard We have something like "draft pull requests" for this.

@stanri, yes, my manager gave me the go ahead to work on this and create a proof of concept, which is what my pull request contained. This permission was informal in the sense that no jira ticket or GitHub issue was created for it.

@keshlam, I planned to edit this question as per your suggestion, but the comments are referring to some of what I would edit. For example, putting up the PR. Let me know if you still want me to edit this.

Keep in mind the expression "If it ain't broke, don't fix it.". Efficiency isn't necessarily a priority over a proven system that everyone understands now. Resistance to process change is not unusual or even necessarily bad.

@StephenG-HelpUkraine, i get your point and I certainly have resisted my share of process change. How would you balance the benefit of a proven system everyone understands with the importance of making a positive impact on metrics like the time it takes to make a change to the codebase?

@mobileDev14 I rate metrics very low on my list of important factors and, more importantly, you need to work out the risk. Saving e.g. 5 minutes a day of everyone's time sounds great if it doesn't come at a risk of screwing up an important client's requirements in the future. You also need to factor in the time someone may have to spend on e.g. supporting a new bit of software that implements the change. Everything costs hours and cash.