-
Notifications
You must be signed in to change notification settings - Fork 5
feat(developer guides): create initial guides for hiring developers, … #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,53 @@ | ||||||
| # Getting Hired (for Developers) | ||||||
|
|
||||||
| Thank you to [itinerare](https://github.com/itinerare) for providing the basis of this guide! | ||||||
|
|
||||||
| Lorekeeper as a whole is a very artist centered community. While code commissions have points in common with (likely more familiar) art commissions, they also have differences that can make for some pitfalls— both for those taking commissions and for those commissioning work. | ||||||
|
|
||||||
| If you're looking to hire individuals for your project, we recommend reading [Hiring Developers](hiring-devs.md) first to understand what to look for and how to set expectations. If you want to get hired, we also recommend reading this! It will help you understand some of the concerns project owners may have and recommended practices to follow. | ||||||
|
|
||||||
| ## Before Getting Hired | ||||||
|
|
||||||
| Before taking on any work, make sure you have the following in place: | ||||||
|
|
||||||
| - Aim to communicate to the best of your ability, including when delays occur. | ||||||
| - Be clear about what you can and cannot do (or will or will not do, depending) and what specific types of work you’re taking on. | ||||||
| - This both sets clear expectations and may help provide clarity for potential commissioners who may not have the same background and understanding of what work they’re looking for. | ||||||
| - Provide some examples of your prior work! | ||||||
| - These might take the form of extension(s) or site-specific features you’ve developed, layout or CSS work you’ve done, etc. | ||||||
| - This both demonstrates your abilities and helps make sure potential commissioners have clear expectations about what kind of work you can do/have done. | ||||||
| - Be clear about your rates and payment terms. | ||||||
| - Do you charge a flat fee or hourly rate? If hourly, what is your rate? | ||||||
| - Have a Terms of Service (ToS), and make sure that anyone you’re working with agrees to it in writing! | ||||||
| - If you don’t have one, consider creating one. It protects both parties. | ||||||
| - Also make sure that it is readily accessible e.g. outside of Discord and can be linked to and/or referenced easily. | ||||||
|
|
||||||
| In fact, the ToS is so important that we recommend not working with anyone who does not have one, or who refuses to agree to yours. In fact, it is so so important, we are going to have an entire section dedicated to it: | ||||||
|
|
||||||
| ### Terms of Service (ToS) | ||||||
| The purpose of this document is manifold. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it might work better to move the last couple sentences from the prior section here and tweak it to be a bit more formal; something like...
Suggested change
|
||||||
|
|
||||||
| Broadly, it should communicate: | ||||||
|
|
||||||
| - Your expectations for a commissioner. | ||||||
| - What expectations a commissioner can have of you. | ||||||
| **And more specifically:** | ||||||
| - Under what circumstances work is being done, on what timetable(s), etc. | ||||||
| - How are changes handled? What about additional work? | ||||||
| - How is payment expected? When is it expected? | ||||||
| - If you have a non-flat-fee cost for something, how is that handled? | ||||||
| - Do you take payment plans for work costing larger amounts? how does that work, if so? | ||||||
| - How do you handle refunds? Under what circumstances will you issue one? How much is it? | ||||||
|
|
||||||
| It’s also worth having something akin to a very finite warranty included in your ToS. | ||||||
|
|
||||||
| That is to say, it’s generally reasonable to promise that code works as intended at the outset/on delivery, and resolve any issues that come up in that context. | ||||||
|
|
||||||
| However, it’s not practical to be responsible for its maintenance in perpetuity, especially if it breaks as a consequence of others’ actions, updates, etc. | ||||||
|
|
||||||
| !!! warning | ||||||
| Note that this does not necessarily preclude you from taking on additional work to maintain it, including for pay, just absolve you of the obligation to do so. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should probably be moved from a callout back to plain text... I'm not sure it needs to be in one, but perhaps more importantly, the one after it is really important and shouldn't be "upstaged", if that makes sense. |
||||||
|
|
||||||
| !!! danger | ||||||
| Remember that your ToS is not a polite request for people to abide by if they feel like it. | ||||||
| It exists for the mutual safety of you *and* your commissioner(s); be ready both to abide by it, *and*, if need be, enforce it. | ||||||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,62 @@ | ||||||
| # Hiring Developers | ||||||
|
|
||||||
| Often, Lorekeeper owners will find themselves in need of additional development help to build or maintain their site. Whether it's a one-time request or ongoing maintenance, hiring the right developer(s) can make a significant difference in the success of your project. | ||||||
|
|
||||||
| We recommend reading the [Getting Hired Guide](getting-hired.md) if you're a developer looking to work on Lorekeeper projects. It's also a good resource for project owners to understand what to expect from developers. | ||||||
|
|
||||||
| If planning on hiring multiple developers, we recommend reading [Working With Multiple Developers](working-with-multiple-devs.md) first and understanding the best practices for collaboration. | ||||||
|
|
||||||
| ## Prerequisites | ||||||
|
|
||||||
| Before hiring a developer, ensure you have the following in place: | ||||||
|
|
||||||
| - Have a clear understanding of what work you want done *before* looking to hire a developer. | ||||||
| - Make sure you understand what circumstances any potential work is being done under. | ||||||
| **What does that mean?** | ||||||
| - Is the work private, or will it become public at some time after completion? When? | ||||||
| - Check (or ask) up front if the person you’re working with has a Terms of Service (ToS)! | ||||||
| - If they do, make sure you read and understand it before agreeing to work with them. | ||||||
| - If they don’t, consider asking them to create one. It protects both parties. | ||||||
|
|
||||||
| !!! danger | ||||||
| Remember that a ToS is not a polite request for people to abide by if they feel like it. | ||||||
| It exists for the mutual safety of you *and* your developer(s); be ready both to abide by it, *and*, if need be, enforce it. | ||||||
|
|
||||||
| ## Where to Find Developers | ||||||
|
|
||||||
| 1. **Lorekeeper Discord:** The official Lorekeeper Discord server has a community of developers who may be available for hire. You can post in the appropriate channels to find interested parties. | ||||||
| 2. **Toyhou.se:** This platform has a section for seeking services. | ||||||
|
|
||||||
| !!! warning | ||||||
| Be extremely cautious when hiring developers from third party platforms. Ensure the developer has relevant experience. We personally DO NOT recommend hiring developers without prior Lorekeeper experience, as the learning curve can be steep. | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Formatting nitpick here, but the message is solid. |
||||||
|
|
||||||
| ## What to Look For | ||||||
| When hiring developers for your Lorekeeper site, consider the following: | ||||||
|
|
||||||
| - **Experience with Lorekeeper:** Familiarity with the project can significantly reduce onboarding time. | ||||||
| - **Portfolio:** Review their past work to gauge their skill level, particularly if you have tight deadlines or specific requirements in mind. See what other work the person you’re working with has done that is in line with what you’re looking to commission. | ||||||
| - This can help make sure that potential work done is of good quality, as well as in the vein you’re looking for (depending on the nature of the potential commission). | ||||||
| - **References:** If possible, speak with previous clients for further insight. | ||||||
|
|
||||||
| ## Setting Expectations | ||||||
| Before starting work, ensure that both parties have a clear understanding of: | ||||||
|
|
||||||
| - **Scope of Work:** Define what tasks need to be completed clearly. Consider using a task management tool to track progress. | ||||||
|
|
||||||
| - **Access:** Determine what access the developer will need (e.g., GitHub, hosting, etc.) | ||||||
|
|
||||||
| - **Timeline:** Set realistic deadlines for deliverables. | ||||||
| - While it’s reasonable to ask for updates, please keep in mind that those you’re working with also have their own lives, and may do other work even in the midst of your commission. | ||||||
| - Abide by their ToS if it has instructions for this, or otherwise ask after updates about once a week at most frequent (as a baseline). | ||||||
|
|
||||||
| - **Payment Terms:** Agree on rates and payment schedules. | ||||||
| - While this might seem obvious for work that costs a flat fee, when dealing with programming work, it’s just as likely that it’s charged at an hourly rate. | ||||||
| - Make sure you’re aware of which it is, and if dealing with an hourly rate, how long the work will potentially take. In short, get an estimate/ask for a quote! | ||||||
|
|
||||||
| !!! warning | ||||||
| You should do this before committing to anything. | ||||||
|
|
||||||
| ## Conclusion | ||||||
| Hiring developers for your Lorekeeper project can be a straightforward process if you take the time to prepare and set clear expectations, both for yourself and potential developers. | ||||||
|
|
||||||
| By following the guidelines outlined in this document, you can find the right talent to help bring your project to life whilst minimizing potential pitfalls. | ||||||
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,63 @@ | ||||||||||||||
| # Working with Multiple Developers | ||||||||||||||
|
|
||||||||||||||
| When collaborating with multiple developers on a Lorekeeper project, it's essential to establish clear guidelines and best practices to ensure effective collaboration and minimize conflicts. | ||||||||||||||
|
|
||||||||||||||
| ## The Golden Rules | ||||||||||||||
|
|
||||||||||||||
| These are written in absolutes, but they are just guidelines to help you and your hired devs work effectively together. Feel free to use as many or as little as you like, whatever works best for your team! | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| ### **For the Project Manager / Lead:** | ||||||||||||||
|
|
||||||||||||||
| - Define clear tasks for each developer. Set deadlines as needed. | ||||||||||||||
| - Use a shared repository separate from your production site (e.g. GitHub). | ||||||||||||||
| - Use a kanban board or similar tool to track progress and tasks. (ex. Trello, GitHub issues, Discord threads, whatever works for your team) | ||||||||||||||
| - If possible, limit access to your live site to only those who absolutely need it. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe |
||||||||||||||
| - Why limit access? Unfortunately, bad actors exist. The fewer people with access, the lower the risk of something going wrong. | ||||||||||||||
| - Enforce code reviews and testing before merging changes. | ||||||||||||||
| - Use the following template if you'd like: | ||||||||||||||
| ```md | ||||||||||||||
| - **Purpose of Changes:** Briefly describe what this change is intended to accomplish. | ||||||||||||||
| - **Issue Link (Optional):** Link to the relevant issue or task description. | ||||||||||||||
| - **Screenshots (if applicable):** Include any relevant screenshots or visual aids. | ||||||||||||||
| - **Additional Notes:** Any other information that reviewers should be aware of. | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| !!! info "Think of it like this:" | ||||||||||||||
| Just like how we have at least two people review MYOs to make sure it's correct, having a second set of eyes review code changes helps catch mistakes, improve code quality, and share knowledge among the team. | ||||||||||||||
|
|
||||||||||||||
| !!! warning | ||||||||||||||
| This is not a substitute for proper testing. All changes should be tested in a development/staging environment before being merged. | ||||||||||||||
|
|
||||||||||||||
| **Note:** Not all developers have the experience or time to review code. If you expect code reviews, make sure your team is on board and has the capacity to do so. | ||||||||||||||
|
|
||||||||||||||
| #### Environments | ||||||||||||||
|
|
||||||||||||||
| Most Lorekeeper projects will have at least two environments, it's good to at least be familiar with the concepts: | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tweaks for formality/formatting nitpicks...
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| - Local / Dev — each dev works on their own machine. | ||||||||||||||
| - Staging / QA / Testing — a shared testing environment. Many sites WILL NOT have a staging environment. | ||||||||||||||
| - Production / Live — the site your users see and interact with. | ||||||||||||||
|
|
||||||||||||||
| --- | ||||||||||||||
|
|
||||||||||||||
| ### **For the Developers:** | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it'd be good to add a little segue here...
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| - All work happens in a hosted repository (e.g. GitHub), NOT the live site. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||
| - Use branches for every change, no exceptions. | ||||||||||||||
| - Nothing goes straight to “live”. NEVER MODIFY CODE DIRECTLY ON LIVE. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Formatting nitpick, but also I think it's a good idea to clarify what this means...
Suggested change
|
||||||||||||||
| Changes flow: | ||||||||||||||
| feature branch → pull request → review → staging (optional) → production. | ||||||||||||||
| - When possible, get features reviewed by at least one other person. It's not just about code quality, but also about shared knowledge. It makes it harder if only one person knows how something works. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a really good point!! |
||||||||||||||
| - Small, frequent pull requests beat big ones that are hard to review. | ||||||||||||||
| - Write clear, descriptive commit messages. We recommend using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format. | ||||||||||||||
| - Definition of Done = works as described, tested, and documented. Make sure you ask for clarification if something is unclear. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||
| - Communicate with your team if something is blocked or taking longer than expected. | ||||||||||||||
| - Write things down (how to run, how to deploy, what changed...) | ||||||||||||||
|
|
||||||||||||||
| ## Branching Strategy | ||||||||||||||
|
|
||||||||||||||
| `main` — production-ready code. | ||||||||||||||
| `dev` — integration branch if lots of parallel work. | ||||||||||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Personally, I also use
Suggested change
|
||||||||||||||
| `feature/<short-name>` — one branch per feature (e.g., `feature/character-subtypes`). | ||||||||||||||
| `hotfix/<short-name>` — for urgent production fixes. | ||||||||||||||
|
|
||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is thoughtful, but I think fine to omit-- and keeps the docs cleaner. At the end of the day, it's a group effort anyhow!