Skip to main content
The previous pages explain the rules. This page turns them into five complete runs you can follow exactly, in order of difficulty. Each assumes you have done Local setup.

​
Scenario 1: fix a typo on the docs site

The smallest possible contribution, good for learning the fork and PR flow.
1

Fork and clone

Fork biznetgio-docs if you plan to send a PR, then clone:
The command clones upstream; to push a branch, clone your fork from your fork’s page the same way.
2

Find the page and fix both languages

Say the typo is on /quickstart. The English copy is quickstart.mdx, the Indonesian copy is id/quickstart.mdx. Fix the English first, then apply the equivalent fix to the Indonesian page. If the Indonesian sentence does not exist verbatim, fix the meaning, not the words.
3

Preview locally

Check both languages with the language switcher in the top bar.
4

Commit and push

5

Open the PR

Open the PR against the upstream main. Mention which page and which language. The maintainer squash merges, and the Mintlify app redeploys the site from main automatically within minutes.

​
Scenario 2: add a new Terraform example

Say the provider gained a new data source for NEO Lite and you want an example showing it.
1

Branch from a fresh main

This clones upstream directly; fork first and clone your fork if you will push a branch.
2

Edit the example

If the data source belongs in the existing NEO Lite story, add it to neolite/main.tf with the bilingual banner and section comments, following Conventions. Reference it from a resource or an output so it is actually exercised.
3

Validate

Fix everything until all three pass. If the provider has a name limit on something you added, shorten the name.
4

Update the docs and READMEs in the same PR

The root README table says neolite/ covers “all 5” data sources; bump the count. If the docs site has a page showing NEO Lite data sources, update terraform/resources/neolite.mdx and id/terraform/resources/neolite.mdx in the docs repo.
5

Commit, push, open the PR

Fill the PR template checklist honestly, including the README and docs sync boxes.

​
Scenario 3: add a new Pulumi example in TypeScript

1

Copy the closest folder

This clones upstream directly; fork first and clone your fork if you will push a branch.
2

Rewrite the program

Edit typescript/my-new-thing/index.ts: new banner, new resources, same rules. Set the project name in Pulumi.yaml to biznetgio-example-my-new-thing and fix the name field in package.json to match. Keep payWithCreditCard defaulting to false, one-shot options commented out, and toAccountId wherever an id meets a number typed input.
3

Build and preview

Type errors at this stage are almost always a missed toAccountId or a property that does not exist, like keypairId on GpuKeypair. The Pulumi repo guide lists the known ones.
4

Mirror to the other five languages

Copy the equivalent existing example in each language and translate the program the same way. YAML gets the flat version. Comments stay identical in spirit, the same bilingual format everywhere.
5

Update READMEs and CI, then open the PR

Root README table, the per-folder READMEs, and the three CI edit points from Pipelines. Then fill the PR checklist and open the PR against upstream main.

​
Scenario 4: mirror an existing example into a new Pulumi language

The mechanics of the “other five languages” step from Scenario 3, done properly for one language:
  1. Pick the language you know and copy the six folders of an existing language, renaming nothing yet.
  2. For each folder, replace the program file with the new language’s version, keeping the bilingual comments. Translate the structure, never invent behavior: same resources, same defaults, same order.
  3. Write the new language’s dependency file with the pinned versions from Conventions.
  4. Build each folder with the language’s command from Local setup, fixing type errors one by one.
  5. Update the root README only if it lists language coverage, and add the language to the CI in the three places Pipelines names.
If the whole thing is a new language rather than a mirror, open a feature request first per Communication.

​
Scenario 5: report a bug you found while using an example

You ran terraform plan in gpu/ and got an error you cannot explain.
  1. Search the repo’s issues and Discussions for the error text first.
  2. Check the docs page for that resource; the GPU quirks are documented on purpose.
  3. If it is new, open a bug issue through the bug report form. Fill in the example folder, your Terraform version, the exact commands, the full error output, and what you expected.
  4. Wait for triage. If the maintainer says it is a provider bug, they will move it to the provider repo, and you can follow the fix there.
  5. If you also know the fix for the example or docs, say so in the issue, then send the PR once the issue confirms the direction.

​
What to do when you are stuck

  • Re-read the Terraform repo guide or Pulumi repo guide for the area you are touching.
  • Open a Discussion with your current code and the error. That is exactly what Discussions are for.
  • Keep the PR draft while you figure it out; the review thread is a fine place to ask once the PR exists.