diff --git a/src/pages/blog/2026-06-12-contributing-to-graphql-without-being-an-expert.mdx b/src/pages/blog/2026-06-12-contributing-to-graphql-without-being-an-expert.mdx
new file mode 100644
index 0000000000..ffce89ce3a
--- /dev/null
+++ b/src/pages/blog/2026-06-12-contributing-to-graphql-without-being-an-expert.mdx
@@ -0,0 +1,138 @@
+---
+title: "Contributing to GraphQL Without Being an Expert"
+tags: ["blog"]
+date: 2026-06-12
+byline: Ayush More
+featured: true
+---
+A practical guide for developers, writers, and community builders looking to make their first meaningful contribution to the GraphQL ecosystem.
+
+## You Don't Need to Be an Expert to Contribute
+
+One of the most common misconceptions about contributing to open source projects like GraphQL is that expertise is a prerequisite. It isn't.
+
+Many developers hold back because they believe contributors are seasoned engineers who have spent years mastering the spec and never need to ask foundational questions. That assumption is incorrect and it keeps a lot of capable people on the sidelines.
+
+The GraphQL ecosystem needs people at every level, with every kind of skill. Documentation needs improving, issues need triaging, community members need guidance, and code needs writing.
+
+If you have used GraphQL even once, you already have something to offer. If you are just getting started but willing to learn and engage, you still have something to offer.
+
+This guide is for anyone who has wanted to contribute but did not know where to begin, felt too intimidated to try, or did not realise that contribution extends well beyond writing code.
+
+## Understanding the GraphQL Ecosystem
+
+Before contributing, it helps to understand how the ecosystem is structured. It can feel overwhelming at first but it is organized in a way that becomes clear once you see the full picture.
+
+GraphQL is a specification, not a library. The [GraphQL spec](https://github.com/graphql/graphql-spec) defines how GraphQL should work, the query language, the type system, and the execution model. Everything else is built on top of it.
+
+**The key repositories you should know:**
+
+- **graphql-spec** — The specification itself. Where language-level proposals and changes are discussed.
+- **graphql-js** — The reference implementation in JavaScript. Most other implementations follow what happens here.
+- **graphiql** — The in-browser IDE for GraphQL. If you have ever run a GraphQL query in a browser, you have used this.
+- **graphql.github.io** — The graphql.org website and blog. Docs, guides, and community content live here.
+- **graphql-over-http** — The spec that defines how GraphQL should behave over HTTP.
+
+Beyond these, there are community-maintained libraries including clients like Apollo and urql, servers like Yoga and Mercurius, and tools like GraphQL Inspector and Hive. All independent projects with their own contribution processes and welcoming to new contributors.
+
+You do not need to understand all of this on day one. What matters is knowing the ecosystem is organized and that different parts of it need different kinds of help.
+
+## Where Do You Fit?
+
+A common barrier to contribution is the belief that there is only one way to participate, which is to write code, open pull requests, and get things merged. That is far from the full picture.
+
+- **Developer** — Fix bugs, implement features, review PRs, write tests, or contribute to tooling. Start with `good first issue` labels in repositories like graphql-js or graphiql.
+- **Technical writer** — The GraphQL docs have gaps. Guides go out of date. Examples become stale. If you can read code and communicate it clearly, your contributions are genuinely valuable. The graphql.github.io repository is a strong starting point.
+- **Designer** — GraphiQL and other tools consistently benefit from UX improvements. Improving error messages or interface clarity is a meaningful contribution.
+- **Community builder** — Answering questions on Discord, supporting beginners in GitHub Discussions, writing blog posts, creating educational content, speaking at meetups. The GraphQL community grows because people show up and make it welcoming.
+- **Student or early-career contributor** — You are not too early. Document something that confused you when you first encountered it. That contribution directly helps the next person who arrives with the same question.
+
+The right question to ask yourself is: what do I already do well, and where in the ecosystem does that skill have a home?
+
+## How to Start Contributing
+
+The most difficult part of contributing to an open source project is rarely the technical work. It is taking that first step.
+
+**Start by reading, not doing.** Before opening an issue or submitting a PR, spend time reading. Review open issues, study recent pull requests, and observe how maintainers communicate. This context saves you significant time and helps you understand what the project actually needs.
+
+**Find your first issue.** Look for `good first issue`, `help wanted`, or `documentation` labels. Begin with something small like a typo correction, a documentation improvement, or a missing example. The goal at this stage is learning the contribution process, not the scale of the change.
+
+**Set up your environment early.** Do not wait for the perfect issue before setting up your local environment. Clone the repository, run the tests, and confirm everything works.
+
+**Communicate before you build.** For anything non-trivial, leave a comment on the issue before starting work. Describe your intended approach and ask whether it aligns with the project direction. This prevents investing hours in something that will not be accepted.
+
+## Contributing Efficiently
+
+Once you have made your first contribution, the focus shifts from getting something merged to making a sustained and meaningful impact.
+
+**On documentation:** Documentation is one of the highest-leverage areas to contribute. A well-written explanation helps hundreds of developers avoid opening an issue because they found the answer themselves.
+
+When contributing to docs:
+
+- Address what confused you. If something took an hour to figure out, document it clearly so the next person resolves it in minutes.
+- Keep examples simple and grounded. Developers learn more from examples than from abstract definitions.
+- Go beyond fixing typos and improve overall clarity. A technically accurate but confusing paragraph is still a problem worth solving.
+- Review the repository's style guide before writing. graphql.org has one and following it makes your PR easier to review and merge.
+
+**On pull requests:** Keep it small and focused with one concern per PR. Write a clear title and description, explain what changed and why, and link to the relevant issue. Respond to review comments promptly. A PR that goes quiet for weeks loses momentum.
+
+**On working with maintainers:** Maintainers are often volunteers. Research thoroughly before asking questions, remain open to feedback, and treat revision requests as part of the collaborative process rather than personal criticism.
+
+**On larger contributions:** Open an issue before writing any code. Describe the problem you are solving and confirm the approach is appropriate. This saves time for everyone involved.
+
+## Non-Code Contributions
+
+One of the most persistent misconceptions about open source is that contribution means writing code. It does not.
+
+Some of the most impactful contributions to the GraphQL ecosystem have been a well-written blog post, a tutorial that helped hundreds of developers, or a community space that made someone feel welcome enough to stay and grow.
+
+- **Writing and blogging** — The graphql.org blog accepts community contributions. Write about your experience adopting GraphQL, a problem you worked through, or a beginner guide you wish had existed when you were starting out.
+- **Videos and educational content** — Short explainer videos, tool walkthroughs, or recorded talks all contribute to how the community learns. A clear screen recording with good audio is sufficient.
+- **Community building** — Answering questions on Discord, supporting people in GitHub Discussions, and welcoming new members is meaningful work. Communities depend on people who show up consistently and make the environment better.
+- **Social media and advocacy** — Sharing what you have learned and writing about ecosystem developments helps the community grow. Contributors have more reach than they often realize.
+- **Translation** — Writing content in your native language makes GraphQL accessible to developers who would otherwise be excluded. That is a significant and often underappreciated contribution.
+- **Speaking at events** — GraphQL Day, GraphQLConf, local meetups, and API-focused conferences are consistently looking for speakers. You need a real story, a clear perspective, and the willingness to share it.
+
+## Do's and Don'ts
+
+**Do:**
+
+- Review existing issues and PRs before opening a new one. The question may already be addressed.
+- Start small. A well-scoped contribution is more valuable than an ambitious one that is difficult to review.
+- Read the repository's CONTRIBUTING.md before doing anything else.
+- Be patient. A delayed response from a maintainer is not a rejection.
+- Provide context in your PRs. Explain what changed, why it changed, and what problem it solves.
+
+**Don't:**
+
+- Open a large PR without prior discussion. Validate the approach first.
+- Take review feedback personally. Constructive criticism is a normal part of the process.
+- Duplicate existing issues. Search before opening a new one.
+- Go silent after opening a PR. If you need more time, communicate that.
+- Over-engineer. A simple solution that solves the actual problem is almost always preferred.
+
+Maintainers are looking for contributors who communicate clearly, scope their work well, and engage constructively with feedback. Technical skills develop over time. The habits you bring to the work are what determine whether you become a long-term contributor.
+
+## What a Great Contributor Looks Like
+
+The most impactful contributors in the GraphQL ecosystem are not necessarily the most technically advanced. They are the ones who show up consistently, communicate clearly, and make the people around them more effective.
+
+A great contributor:
+
+- **Is curious, not just capable** — They ask thoughtful questions and seek to understand the problem before proposing a solution.
+- **Communicates clearly and proactively** — They surface blockers early, respond to feedback, and keep work moving. Clear communication is often more valuable than technical skill.
+- **Starts small and builds trust** — They do focused work well and earn credibility over time through consistent and reliable action.
+- **Receives feedback constructively** — They understand that code review is collaborative and that better outcomes come from engaging with feedback.
+- **Shows up over time** — Twelve months of consistent contribution including fixing issues, supporting others, and improving documentation is what builds lasting impact.
+
+These are not standards to meet on day one. They are behaviors worth developing over time.
+
+## Resources
+
+- [graphql.org](https://graphql.org) — Official documentation and website
+- [GraphQL GitHub Organization](https://github.com/graphql) — All foundation repositories
+- [GraphQL Discord](https://discord.graphql.org) — Primary community space
+- [Working Group Notes](https://github.com/graphql/graphql-wg) — Follow spec development
+- [Good First Issues](https://github.com/graphql/graphql-js/labels/good%20first%20issue) — Starting point for graphql-js
+- [GraphQL Ambassador Program](https://graphql.org/community/ambassador-program) — Learn about the program
+- [GraphQL Foundation](https://graphql.org/foundation) — Learn about the foundation
\ No newline at end of file