Welcome to the Tech Contributor team! You've been invited because you stood out to the TAdmin team as an outstanding member of the community with coding skills.

This guide will go over most information you'll need to know. This can be referenced at any time in case needed!

What is a Tech Contributor?

A Tech Contributor (shortened to TC) is a player from the community who expresses a solid understanding of Java programming and has an interest in assisting the TAdmins in maintaining server plugins and software needed to keep the servers in tip-top shape.

TCs won't have any in-game permissions different to those of a normal player as you're not a moderator or admin. This role is pretty much the same as a normal player but with access to direct communication with the TAdmins and useful information the TAdmins have that could be used when updating plugins.

Key Responsibilities

• Developing, updating, and maintaining plugins as requested by the TAdmins.
• Collaborating with the TAdmins to discuss feature implementations and bug fixes.
• Submitting pull requests to the GitHub repository for review.
• Participating in discussions in the dedicated Tech Contributor Discord channel.
• Is willing to learn, has an open mind, and is ready to have fun!

---

Onboarding

This is the flow that the TAdmin onboarding you will use:

Pre-onboarding

• Reach out to the player and ask if they would like to join the team.
• Grant access to the discord channel.
• Discuss a time to have a Discord call or something of the sort.
  • This is the easiest way to go through the orientation. If not able to, over text is also perfectly fine!

During the Call

• Explain that this isn't a promotion and that they won't be gaining any extra permissions.
• Go over the key responsibilities with them.
• Explain that any work being done shouldn't be talked about in public without the approval of a TAdmin. Some work being done may be secret.
• Grant the user access to the Tech Contributor Vikunja board.
  • Explain the TAdmin policies regarding Vikunja and how we deal with things.
  • Tech Contributors will have their own board with their own rules. See the section below on this.
• Explain Nerd's plugin licensing and what that means for them and their code.
• Look over what IDE they use and help them get set up for development on the latest version, should they not already have that set up.
• Go over Spigot/PaperMC. What is it? How do you start a plugin with it? Explain the plugin structure as well as Gradle. Also introduce them to the Paper javadocs.
• Have them write a plugin after the call that adds a command and event that both return an output of some kind to the player so we know they work.

Post-Call

• Review the simple plugin that the player made with them.
  • Check to make sure the plugin works.
  • Check the code for any errors or inefficient parts.
  • Provide them with explanations for anything they're uncertain about or any errors noticed
• Have the player look over the list of bugs, feature requests, or maintenance cards on their own board and pick one they want to try to tackle first.

---

Access

As mentioned above, you will need access to some Nerd services to complete tasks. Below is the access needed:

• Vikunja - Tech Contributor team.
  • Why? For claiming, actioning, and completing tasks in our boards..
• Discord - Tech Contributor role.
  • Why? For access to the Tech Contributor channel for direct communication with the TAdmins.
• Nerd.Nu website - Tech Contributor group.
  • Why? For reading the TC-related documents.

What access is different from TAdmins?

You will NOT have access to the following:

• The server boxes.
• In-game permissions (they will keep the Default role).
• The GitHub beyond normal public access for making issues and PRs.
• Admin chats on the Discord.
• The TAdmin board on Vikunja to avoid them seeing sensitive information that could end up there.

---

Vikunja

Vikunja is the tool we use to keep track of tasks and collaborate more efficiently. It's very similar to Trello except we don't have to pay to use it and we self-host it on our own servers.

As a TC, you have your own board called "Tech Contributors". This is where you'll do everything. Anything in that board is what you'll be working with/on and is an ongoing task.

Layout of the Board

In Vikunja, each column that holds cards/tickets/tasks is called a bucket. The TC board has 5 buckets for tracking types and progress of cards.

• Bugs: For cards that describe a bug with a plugin or software relating to a Nerd.Nu service.
• Feature/Modification Requests: For cards that are requesting a new feature or modification for one of Nerd's softwares.
• Maintenance: Where tracking cards go. This bucket will have one card representing a plugin that has at least one card in the above 2 buckets. Any cards in the other buckets will be childed to these cards for easy tracking. For major version updates, an additional card will be present for tracking update progress.
• In Progress: Where cards that are claimed by someone are placed so everyone knows that they're being worked on. When updating one card in the first 2 buckets when multiple are present for a plugin, place just that card in this bucket. If completely updating the plugin with all cards for it on the board, bring the tracking card over too.
• Complete: For cards that are updated, tested, run through the Snapshot server, and are deemed functional enough for the production servers.

How Cards Reach This Board

TAdmins will move cards into the TC board as we come across bugs and feature requests that we deem appropriate for your team to handle. These cards will come from all over the Vikunja as we have boards for moderators, PAdmins, CAdmins, HAdmins, and some other project-specific boards.

TAdmins will verify all needed information is present and also attach tags to the card before moving it in. Should you believe another tag should be added, please use the proper tag from the card with all of the tags and don't make a new one. Tags are per-person on Vikunja unless already present in a board, so the tag card can be used to pull tags.

Example Flow of a Card

Below is an example of a flow a typical plugin may follow:

1. The bug is reported and added to the Vikunja board.
2. TAdmins triage the card, gather necessary information, and, if applicable, move the card to the TC board.
3. A TC sees the card and it's unassigned and sitting in one of the first 3 buckets.
4. The TC reaches out to the TAdmins to ask if they can work on that card (and any other related ones).
5. If approval is granted, the TC may assign themselves to the card(s) and move them to the In Progress bucket.
6. The TC pulls the code from GitHub and updates it. Follow the update flow for stuff between this and the next step.
7. Once the plugin is complete testing and is deemed complete by the TAdmins, move to the Complete bucket.

---

Tasks and Update Flow

As a TC, taking on tasks like updating plugins is going to be one of your main responsibilities. The TAdmins will move tasks that we think are appropriate into your board as they come in and you can claim them to start coding away. One thing, though - you need TAdmin approval first.

Some tasks can be more challenging than others and we don't want to drown you in complex code. For this reason, you'll need to ping the TAdmins in the TC Discord channel and let us know the card # and/or name so we can take a look at the task. If approved, follow the update flow to update your plugin. If denied, no worries! There'll be more tasks.

Update Flow

1. TC reaches out to TAdmins and asks if they can work on a card/plugin.
2. TAdmins approve and assign the user to the card(s) if user hasn't already done so.
3. TC updates the code.
4. TC tests their plugin on their local dev server. Performance testing is optional but highly appreciated.
5. TC makes a GitHub PR for the plugin and a TAdmin reviews the code and gives tips, fixes, and any other helpful information.
6. TAdmins compile the plugin and do our own testing on the dev network. Test functionality, performance (CPU, memory, and main thread usage), and anything else that could be an issue.
7. If all is well, TAdmins load the plugin onto the Snapshot server for public stress-testing. Test functionality, performance (CPU, memory, and main thread usage), and anything else that could be an issue.
8. If plugin passes Snapshot testing, remove plugin if needed or keep on the server.
9. Notify TC of the results, discuss them and answer any questions TC has.
10. Discuss plugin addition to production servers with server admins, demo if it has new features/modifications, and roll it out as decided.

---

Concerns

There are a number of concerns that come with this role, as there is with any role. Please keep these in mind when working with the TAdmins.

---