This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Contribution Guidelines

How to contribute to the AMYBO community

Reach out to us

Please add a comment to one of our YouTube videos or drop us a line at hello@AMYBO.org with any suggestions or questions you may have - or just to say hello, it’s good to know people are reading this.

If you’re comfortable with GitHub (or would like to learn) we’d absolutely love it if you were happy to dive in and edit our pages directly:

Editing AMYBO.org

We welcome contributions and improvements to the AMYBO.org website. We want this to be as easy as possible so considered a wiki. However, given the controversial nature and risks associated with protein production for human consumption, we decided that an approvals process was required.

Since we’ll be using GitHub for software development, and potentially also for hardware and procedure development, it made sense to use this for community development of the website. If you struggle at all with GitHub development, please get in touch via hello@AMYBO.org

Web stack

We use Hugo to format and generate our website, the Docsy theme for styling and site structure, and Netlify to manage the deployment of the site. Hugo is an open-source static site generator that provides us with templates, content organisation in a standard directory structure, and a website generation engine. You write the pages in Markdown (or HTML if you want), and Hugo wraps them up into a website.

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Quick start

Here’s a quick guide to updating the docs. It assumes you’re familiar with the GitHub workflow and you’re happy to use the automated preview of your doc updates:

  1. Fork the AMYBO pages repo on GitHub.
  2. Make your changes and send a pull request (PR).
  3. If you’re not yet ready for a review, add “WIP” to the PR name to indicate it’s a work in progress. (Don’t add the Hugo property “draft = true” to the page front matter, because that prevents the auto-deployment of the content preview described in the next point.)
  4. Wait for the automated PR workflow to do some checks. When it’s ready, you should see a comment like this: deploy/netlify — Deploy preview ready!
  5. Click Details to the right of “Deploy preview ready” to see a preview of your updates.
  6. Continue updating your doc and pushing your changes until you’re happy with the content.
  7. When you’re ready for a review, add a comment to the PR, and remove any “WIP” markers.

Updating a single page

If you’ve just spotted something you’d like to change while using the docs, Docsy has a shortcut for you:

  1. Click Edit this page in the top right hand corner of the page.
  2. If you don’t already have an up to date fork of the project repo, you are prompted to get one - click Fork this repository and propose changes or Update your Fork to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
  3. Follow the rest of the Quick start process above to make, preview, and propose your changes.

Previewing your changes locally

If you want to run your own local Hugo server to preview your changes as you work:

  1. Follow the instructions in Getting started to install Hugo and any other tools you need. You’ll need at least Hugo version 0.45 (we recommend using the most recent available version), and it must be the extended version, which supports SCSS.

  2. Fork the AMYBO pages repo repo into your own project, then create a local copy using git clone. Don’t forget to use --recurse-submodules or you won’t pull down some of the code you need to generate a working site.

    git clone --recurse-submodules --depth 1 https://github.com/AMYBO-org/pages

  3. Run hugo server in the site root directory. By default your site will be available at localhost:1313/. Now that you’re serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.

  4. Continue with the usual GitHub workflow to edit files, commit them, push the changes up to your fork, and create a pull request.

Creating an issue

If you’ve found a problem in the docs, but you’re not sure how to fix it yourself, please create an issue in the AMYBO pages repo. You can also create an issue about a specific page by clicking the Create Issue button in the top right hand corner of the page.

Useful resources

1 - Our name & Logo

What’s with the AMYBO name & logo?

Name

AMYBO is a community and we want it to be community led. As such both the name and the logo are placeholders for the community to fill in.

We consider AMYBO to be a placeholder backronym. That is it’s an acronym that stands for something the community still needs to decide on. We’re in no great rush to fill it, as we want to leave space for literary creatives to join us & contribute alongside biotechnologists and developers.

Please reach out to hello@AMYBO.org with any backronym suggestions.

Likewise with the “AMYBO NEEDS A LOGO” logo, we welcome visual creatives to the community & would love to see their take on the logo. Some might say there’s a bit more urgency to the logo than the backronym. Say for example if we wanted to join the APA or any similar logo collection. Without the community explanation, we may look like we’re not taking ourselves seriously.

So what do we want in a logo?

  • It’s common in logo competitions to seek a logo that encapsulates what the organisation does, or its main product(s). But if you look at any lists of the world’s most recognisable logos you’ll probably see <3% that even allude to what the organisation does.
  • Most top logos are just a name, many use an image that conveys an emotion rather than a product: car brands often go with powerful animals or geometric symbols, penguins have been used by OS & book publishers, a small business trying to use a pear logo was famously challenged by a company using a more recognisable fruit…
  • Do we just want a nice font for AMYBO? If so, what do we mean by a nice font?
  • Do we stick with black on white for accessibility, low cost printing & the ability to use different colours for different purposes without going off-brand? Or do we want to pick a specific colour?
  • If we just use AMYBO in a nice font, what do we use for square favicons and circular YouTube logos, etc?

Please let us know your thoughts at hello@AMYBO.org