Closed azarboon closed 5 days ago
Based on your GitHub profile, this looks like you're simply trying to add superfluous PRs to increase your profile. I don't see this as value added and would encourage you to focus on real improvements that are not superficial
Based on your GitHub profile, this looks like you're simply trying to add superfluous PRs to increase your profile. I don't see this as value added and would encourage you to focus on real improvements that are not superficial
@bryantbiggs your comment was unprofessional, to say the least. Nobody has paid me nor will pay me for the free labor I'm putting in here. I'm doing it just to help the community so please stop acting entitled. I really hope your behavior is not representative of this repo's maintainers.
Putting that fallacy in this page, can help some non-observability-practitioners to think about it at least for a few minutes. I, formerly, used to be one of those people who thought observability is optional or it can be delayed.
That fallacy is coined by one of the thought leaders in the field and I'm honored to spread the word, where it matters. My similar PRs have been accepted in official repositories by both AWS e.g. here and Azure, and in Azure documentations (yes, you can track them all on my profile)
@pgasca @fincd-aws @geoffcline @jimdial-aws @judyheflin @lizsnyder @matteofigus @mwunderl @Paul-B-AWS @yanjieniu I'm wondering, is such abusive comment common or tolerated? Below is the screenshot, in case he modifies it.
Basically, I'm trying to spread the word about a common fallacy which is coined by one of the thought leaders in the field. Knowing that fallacy can help novice readers to care about observability, to begin with. My similar PR has been accepted in both AWS and Azure official repositories for example here. I'm a new contributor to this repository and that comment was off-putting, to say the least. Personally attacking a new contributor is not the best welcoming message that he can receive. I've had +25 merged PRs on both AWS and Azure repos. This is the first time I encounter such an abusive behavior and I'm really disappointed. I hope you will take a proper action otherwise he can dissuade other new contributors, too.
I am sorry if my comment upset you that deeply, but I do believe it is an accurate statement. I don't see this behavior of opening multiple 1 line change PRs with subjective statements as something that is solving a pain point/problem or improving on what is provided. Perhaps we can start with an issue first that is describing the situation and work backwards from that before we jump in to proposing changes?
I am sorry if my comment upset you that deeply, but I do believe it is an accurate statement. I don't see this behavior of opening multiple 1 line change PRs with subjective statements as something that is solving a pain point/problem or improving on what is provided. Perhaps we can start with an issue first that is describing the situation and work backwards from that before we jump in to proposing changes?
Go and read the PRs, look at each one's context then express your opinion POLITELY not by making a single comment which has nothing but a personal attacking. I don't know about this repo but in all other official repositories that I've contributed it, none of the maintainers judged my PR based on the fact that it was only one line or a few lines. This speaks volume of your professionalism.
Now, I know that I don't want to contribute anymore neither to this repo or nor to any other repo that you are involved.
Ironically, I made the same PR in other AWS repository which was well accepted.
Let's keep the discussion focused on the content and the utility of the proposed change for customers.
The guidance in this topic is intended to help customers understand the use cases for observability with EKS. I would expect a reader of this document to have some interest in observability and an open mind, and not place any assumptions on them.
The third paragraph of the intro discusses how and why monitoring is important in cloud applications. I think there's room at the end of the intro (after the list of questions) to emphasize why observability is critical to good application architecture, if you can relate it directly to reliability, efficiency, operational excellence, et cetera.
Hi @azarboon
I'm a technical writer who works on maintaining this repo. I noticed you opened several PRs with similar small changes. We welcome contributions. In the future, could you combine small edits into one PR? This helps expedite review and processing.
Thanks! Geoffrey
Thanks for your comment. I can see some positive actions from your side. I'm happy that not everybody in this repo is toxic and abusive.
Regarding your comment: sure, I noted it. FYI, I use corporate laptop so I can use Github on browser. But yes, I'll try to combine my future and relevant PRs into one.
@geoffcline thanks for your constructive feedback. I just moved it to a lower section. Also I considered @mwunderl comment. Feel free to edit it further.
Thanks, you can use the github web based editor to change multiple files at once https://docs.github.com/en/codespaces/the-githubdev-web-based-editor
Thanks, you can use the github web based editor to change multiple files at once https://docs.github.com/en/codespaces/the-githubdev-web-based-editor
Thanks. Yes, I've already combined all my PRs in EKS best practices repo. Kindly please check
https://github.com/aws/aws-eks-best-practices/pull/524#issue-2342105473
Hello! 👋
We are temporarily taking this repository offline for a week while we migrate our documentation from Markdown to AsciiDoc format. As part of this transition, I'm closing older pull requests that haven't seen recent activity.
Feel free to resubmit your contribution after we complete the migration. We value your input and would be happy to review an updated version of your changes that aligns with our new AsciiDoc format.
Thank you for your understanding and continued support of our AWS documentation!
Added a fallacy of distributed computing (observability is optional), so readers know why they should care about observability. It's coined by one of the thought leaders in software architecture Mark Richards.
Here you can briefly familiarize yourself with this fallacy: https://youtu.be/UDtQgXDfkO8
And you can read about it further on these two books: https://a.co/d/4Tsadn3 https://a.co/d/9GFrPtC
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.