How to contribute

Use your favourite STEEM frontend Steemit.com or Busy.org and publish your contributions or task requests by following our Guidelines.
  • Set the first tag of your post: utopian-io
  • Set the second tag of your post based on the category. Each category tag can be found below in the category specific guidelines.
  • In the body of your post always include the link to the github repository at the top, i.e. https://github.com/utopian-io/utopian.io
  • Follow any of the predefined templates to make sure your contribution has a clear format. Each category template can be found below in the category specific guidelines.
  • Once your contribution or task request has been submitted wait up to 72 hours for a Moderator to review it.
  • If your contribution is eligible for an upvote, the main @utopian-io account will vote and comment on your post.

Utopian General Rules

These are the rules that apply, if you want to submit a contribution to Utopian. If you have more general questions about Utopian please refer to ourFrequently Asked Questions.

Failing to adhere to one or more of the rules set below will lead to the immediate rejection of your contribution. Please be sure to read and understand the rules before submitting a contribution.

Utopian moderators / supervisors have the full right to reject or accept submissions and to assess its quality, even if the submission meets all the rules.

Supervisors may revert an accepted / rejected contribution.

Rules vs Guidelines

Some of the instructions in this document are designated as guidelines in italics. Failure to follow these guidelines will not lead to immediate rejection, but instead to a notification from the category Moderator asking the submission to be corrected.

Repeated failures to follow guidelines may lead to the rejection of your submissions.

Bans and Downvotes

The following behaviors may lead to a temporary or permanent ban from Utopian:

  • Harassing any member of the Utopian team.
  • Using multiple accounts to abuse the system.
  • Consistently submitting low quality contributions even after being notified.
  • Plagiarism.
  • Inclusion of licensed or commercial materials or failing to cite the source of Creative Commons media even after being notified.
  • Tag spamming.

Vote and Approval Retraction

  • Submissions found in violation of Utopian rules can be unvoted or rejected even after they have been accepted.
  • Erroneous (accidental) Utopian upvotes will be retracted.

Post Writing and Style

To be accepted, submissions must be written in a formal and professional style. A moderator may reject a contribution if the writing is unprofessional or unclear.

  • The writing style should be formal and informative.
  • The writing style should be professional and clear.

Guidelines:

  • Sentences like: “Hello Utopians, What’s up Steemians, Dear friends” and similar informal greetings may lead to rejection.
  • Images and videos used in contribution submissions should be of high resolution. Low resolution images and videos may be rejected.
  • Submissions with grammar issues that make the content difficult to understand may be rejected.
  • Failure to apply the templates provided in the editor for each category may lead to rejection. The standard contribution submission templates should be followed when detailing your contribution. However, templates can be edited and extended as long as the formatting is clear.
  • Contributors may refer to the following resource when writing contribution submissions - https://owl.english.purdue.edu/owl/resource/656/02/

Contribution Value, Volume and Detail

  • The contribution must add value to the Open Source project. Moderators may reject (at their discretion) submissions that offer little to no added value to the project.
  • The contribution must be informative and contain as much detail as possible describing the work done.
  • When applicable, graphical content like images, charts, videos and screenshots must be included.
  • The length of the body of the contribution should be sufficient to provide a thorough overview of the submitted contribution.
  • Every contributor may only submit ONE contribution post per task request. Use of multiple accounts to circumvent this rule will lead to immediate ban from Utopian services.

Submission Language

Only contribution posts written in plain and easily understood English will be accepted.

Github Integration and Repositories

Unless otherwise specified, Utopian contributors must have an active GitHub account connected to the contributor’s Utopian profile.

  • Only contributions made to open source projects with a GitHub repository can be approved.
  • The Github repository linked to a Utopian contribution post must contain the project’s source code, a readme and a license.
  • A contributor’s Utopian account must be connected to their GitHub account.
  • Contributions for un-official repositories will only be accepted if the repository is listed in Utopian un-official repository whitelist.
  • Contributions for repositories listed on Utopian repository blacklist will be automatically rejected.
  • Contributions on official repositories that are mirrors of another subversioning system will be accepted.
  • Contributions on repositories that have not received any program code updates for longer than 6 months, will be automatically rejected.
  • Contributions on forks that do not have any difference / improvement over the original project will not be accepted.
  • Contributions to repositories that contain books, texts or other types of content but no software code will be rejected.

Submission Originality

All submitted contributions must be unique. Users must check if an identical or very similar contribution has been previously submitted.

  • Duplicate submissions (by the same or different user) will be automatically rejected.
  • Content shared previously will be rejected if a moderator discovers plagiarism, and the user submitting it will be banned from Utopian.

Contribution Authorship

  • The contribution must provide the information necessary to verify the identity of the contributor as the post author.
  • If a contributor’s Steem / Utopian username does not match the username used in an external platform, they must either edit the username on the external platform, or provide alternative means of verification.

Forbidden Content

Commercial / Copyrighted Materials

Submissions and contributions must not include any commercial or copyrighted materials.

  • Images and videos used must be distributed under the Creative Commons license and content source must be cited (when applicable).
  • Contributors assume full responsibility if and when using copyrighted or commercial materials without proper permission.
Spam
  • The contribution should not contain any clear attempt to profit solely from a commercial perspective, and should not be written in a way that suggests the contributor is looking to maximise the returns.
  • The author may include links to his social profiles in his submission if they appear in a non-disruptive way.
  • Links to commercial products and affiliate links are forbidden.
  • Tagging or mentioning other Steem / Utopian users without an appropriate reason should be avoided.
Defamation
  • Contributions and comments must not include offensive speech directed at others.
  • Contributions and comments may not contain false information about another user that may be perceived as defamatory.
Solicitation
  • Contributors should not use submission posts to solicit for any activity that it is not strictly accepted by Utopian Rules.
  • Contributors should not ask for Steem / Steemit engagement (upvotes, resteems and follows) in their contribution posts.
  • Contributors should not ask for Utopian engagement (upvotes and follows) in their contribution posts.
  • Contributors may ask for Steem witness votes in a short request (one paragraph) at the footer of their post.
Religious / Political Content
  • Content that disseminates religious or political ideologies or beliefs of any kind is rejected.

Suggestions Guidelines

Category tag: ideas

Category template: View now

  • Suggestions are minor features / enhancements to an Open Source project.
  • Suggestions may only relate to significant technical aspects of the project (rather than processes or organisational issues).
  • Suggestions must provide all the information and details for the requested features to be actualized.
  • Images, charts, screenshots, links and examples should be included contributions to this category.

Development Guidelines

Category tag: development

Category template: View now

Acceptable submissions in the development category include (1) Bug Fixes; (2) New Features and (3) Contributor’s Own Projects.

  • Contributions must have a comprehensible commit history. Projects or updates submitted in a single commit will not be accepted.
  • Outdated or low quality code will lead to rejection.
  • Generated code or other results of automated processes will not be accepted.
  • Submitted projects must have unique value. Redundant projects will not be accepted.
  • Trivial code snippets, example code or simple templates will not be accepted.
  • Bug Fixes and New Features must be submitted via Pull Requests. The Pull Request must have been merged within the past 14 days.
  • Updates on Own Projects can be committed directly, without a Pull Request. Commits must not be older than 14 days.
  • Bug Fixes for contributor’s Own Projects will not be accepted, unless the Bugs were caused by third party dependencies.
  • The repository must contain a readme file with usage and install instructions, as well as an appropriate open source license.

Bugs Guidelines

Category tag: bug-hunting

Category template: View now

Acceptable contributions in this category must include Bug Reports for actively maintained Open Source projects on GitHub.

  • The repository on GitHub must accept issues.
  • Bug Reports for projects in pre-alpha stage will not be accepted.
  • Cosmetic issues that do not affect the functionality of the software will not be accepted.
  • Submissions must include sufficient detail to reproduce the bug.
  • Submissions must Include information about the debugging technical environment such as Device, Operating System, Browser and Application versions used.
  • Submissions must refer to bugs on the latest released version of the application (not older versions).
  • Submission title must briefly describe the occuring issue and include searchable keywords.
  • Bug Reports previously submitted as issues on GitHub (either by the contribution author or another party), will not be accepted. Approved Bug Reports will automatically be published on GitHub.
  • Submissions should include screenshots, video recordings or animated GIFs if they can help to describe and understand the bug reported.

Graphics Guidelines

Category tag: graphics

Category template: View now

Submissions to this category must include (1) graphics; (2) videos and/or (3) motion graphics created for an open source project by the contributor.

  • Any type of graphics submissions is acceptable only if it was explicitly requested by the project owner or if the contributor can provide a clear proof that their submission has been accepted and used in the project.
  • The submission must be a direct result of the contributor’s own work. It is strictly prohibited to modify other people’s work/assets or use a template and claim it as original work.
  • T-shirts and merchandise production will be rejected.
  • Submissions must include sufficient detail to allow for author verification to ensure the work was done by the contributor.
  • Submissions must contain the final product (downloadable file of the work), sample of the work, applications of it, comparison to the existing product, and benefits of the work to the project owner.
  • Graphics submissions (excluding logo designs) should be delivered in .psd, .ai, .cdr or any other universally accepted file format.
  • Logos must be delivered in a vector file (e.g. .eps/.svg/.pdf) for flexibility and scalability, as well as .png file format for immediate use of the logo.
  • Logo design submissions must contain the actual logo (logomark/logotype), the logo in a form of an app icon in case that the project has a mobile application, logo variations in terms of size and colour (one colour and full-colour versions).
  • Any text or fonts must be converted into shapes or “outlined”.
  • Submissions must include credits to all third-party images/assets used in the contribution. It is up to the contributor to ensure they have permission to use these assets (images, videos, fonts, 3D models etc.) for commercial use.
  • Intro videos are acceptable only if the contributed video replaces an existing one of inferior quality already included in the project or if it was explicitly requested by the project owner.
  • All submissions must be licensed under the creative commons license.
  • All designs should be delivered in a vector format unless otherwise specified by the project owner.
  • Submissions should (ideally) be coordinated with the project owner throughout the design process.

Analyses Guidelines

Category tag: analysis

Category template: View now

Valid submissions to this category must include data analysis generated for an Open Source project.

  • Submissions must include the reasons for the analysis performed and its results.
  • Submissions must include (when applicable) example scripts used for the generation of the results, or extensive information detailing how the data was gathered and analyzed.
  • Submissions must include visual representation of analysis result in the form of charts and tables.
  • Submissions including recurring analyses that are obviously script generated will lead to a lower vote.
  • If submissions include partial analysis, public links to the full analysis must be provided.
  • Submissions containing mainly data visualization without any conclusions or predictions based on the gathered data will be rejected.
  • Analyses of social and behavioural changes of a specific group involved in the project will be rejected.

Visibility Guidelines

Category tag: social

Category template: View now

Submission to this category must include proof of results in online and social media engagement for an Open Source project that was driven by promotional activities on public channels online.

  • Visibility efforts must be explicitly requested by the project owner and meet their requirements. A link to the respective Utopian Task Request must be provided.
  • Before you become active, you must obtain the direct permission of the project owner and clarify the details.
  • Valid submissions to the visibility category are (1) paid search engine and display ads placement; (2) paid social media ads; (3) Thunderclap campaigns and (4) posts to social media accounts with at least 10,000 unique followers.
  • Promotions on chat platforms (e.g. Whatsapp, Telegram and similar) will not be accepted as valid submissions.
  • The campaign must have a total reach of at least 10,000 unique users and proof of valid user engagement (over 1.5% on Twitter and 1% on Facebook).
  • Submissions must include valid and verifiable proof of the visibility activities undertaken including:
  • Downloadable reports (when available) pertaining the activity.
  • Screenshots of the promotional activity from the platform used.
  • Links to promoted content.
  • Ad copy and graphics used in the campaign.
  • An overview of the goals, bidding strategy, details and choice of target audience, reasoning of said choice, as well as results of the campaign.
  • Submissions of campaigns on Open Source projects with more than 100,000 users will be accepted only if the submission includes proof of project owner request for promotional activity performed.
  • Submissions must include proof of authorship by matching the Steem / Utopian account of the contributor to that used in the campaign, or any other means of verification.
  • Ad content and social media messages in any language other than English must be accompanied by a translation.
  • Ad content and targeting chosen must show the contributor’s understanding of the project and experience in its applications and uses.
  • Submission of Instagram campaigns will not be accepted.
  • Low quality ads, ads that containing obvious grammatical and/or copyrighted content will be rejected.

Documentation Guidelines

Category tag: documentation

Category template: View now

Submissions to this category are limited to official documentation of Open Source projects on GitHub.

  • Only merged Pull Requests on the official repository or on a fork will be accepted, as long as the fork is not just a mirror of the original repository.
  • If the submission does not include the full documentation project, public links to it must be provided.
  • Unofficial documentation will not be accepted in this category.

Tutorials Guidelines

Category tag: tutorials

Category template: View now

Submissions to this category must include technical instructions that use text and graphics to clearly explain and teach significant aspects of an Open Source project.

Contributors may refer to the following resource when writing tutorial submissions - https://owl.english.purdue.edu/owl/resource/656/02/.

  • Submissions presenting content creation and simple on-screen instruction will be rejected.
  • End-user focused tutorials must provide clear instruction of substantial project functions that are unique to that specific Open Source project and essential learning requirements for end-users.
  • Submissions addressing only circuit design and/or the build of specific electronic modules will be rejected.
  • Submissions focused on the use of functions that are already well documented in the project documentation will be rejected.
  • Submissions containing substantial instruction in ubiquitous functions (Save, Open, Print, etc.) or basic programming concepts (variables, operators, loops, etc.) will be rejected.
  • Submissions must include the full tutorial in the Utopian post.
  • A submission may be rejected if the moderator provides a link to a superior tutorial on the same subject.
  • Machine translated tutorials will be rejected.
  • Contributors providing a video version of a text tutorial must embed or a link to the video in the post. Contributors cannot submit this video as a separate contribution in the Video Tutorial category.
  • Submissions that include a GitHub repository with additional materials (like code samples), should be linked to the repository of the original project discussed in the tutorial and not the supplementary repository created for the contribution. Links to the supplementary repository for the post should be included in the submission post.
  • Submissions containing unexplained essential steps, codes or examples will be rejected.

Video Tutorials Guidelines

Category tag: video-tutorials

Category template: View now

Submission to this category must include technical instructions that explain and teach significant aspects of an Open Source project, and must be presented in video format.

  • Submissions about the usage of functions which are already well documented in the project documentation are not accepted.
  • End-user focused tutorials must provide clear instruction of substantial project functions that are unique to that specific Open Source project and essential learning requirements for end-users.
  • Tutorials containing process videos, such as gameplay, content creation and simple on-screen instruction will be rejected.
  • Tutorials containing substantial instruction in ubiquitous functions (Save, Open, Print, etc.) or basic programming concepts (variables, operators, loops, etc.) will be rejected.
  • Submissions must include mention of the contributor’s Utopian account name at the beginning of the video.
  • Submissions must include supplementary text following the contribution template found in the Utopian.io contribution editor.
  • A submission may be rejected if the moderator provides a link to a superior tutorial on the same subject.
  • Video tutorials must be presented in an organized and well prepared fashion. Presenters must speak clearly and professionally and videos must not contain any substantial pauses.
  • Video Tutorials using machine generated voice-over will be rejected.
  • Video resolution must be a minimum of 720p (HD). Audio must high quality and not contain any substantial background noise or distortions.
  • Submitted video must be hosted on either YouTube or DTube and embedded in the submission post. The hosting YouTube or DTube account must be clearly associated with the contributor.
  • Submitted video must not be older than 14 days.
  • Contributors providing a text version of a video tutorial must include the text or a link to the text in the post. Contributors cannot submit this text as a separate contribution in the Tutorial category.
  • Submissions that include a GitHub repository with additional materials (like code samples), should be linked to the repository of the original project discussed in the tutorial and not the supplementary repository created for the contribution. Links to the supplementary repository for the post should be included in the submission post.
  • Submissions containing unexplained essential steps, codes or examples will be rejected.
  • Submissions addressing only circuit design and/or the build of specific electronic modules will be rejected.

Copywriting Guidelines

Category tag: copywriting

Category template: View now

Submissions to this category are limited to copywriting of text content for Open Source projects on GitHub.

  • Submissions to this category must include verifiable proof of authorship for the work done.
  • Only merged Pull Requests on the official repository or on a fork will be accepted, as long as the fork is not just a mirror of the original repository.
  • If the submission does not include the full project, public links to it must be provided.

Blog Guidelines

Category tag: blog

Category template: View now

Submissions to this category are designated to promote open source projects and to inform about their development. The post may be one of the following: (1) Project Promotion, (2) Project Introduction, (3) Development Log. Regardless of the type of the blog post, unique and insightful editorial content in a professional format are expected, ideally with high-quality visual supplement.

  • The project introduction and development logs are reserved for project owners and closely collaborating members who have been appointed to publish the article.
  • Project introduction must include detailed roadmaps and overviews. It should contain differences with similar projects and highlight its unique aspects.
  • Development logs should incorporate details of meaningful changes and an overview of new features. Development logs are not meant for minor version changes and bug fixes only. Project owners can't present such posts in blog category if they submitted said information as a development contribution.
  • Project promotion contributions must include author's personal experience with the project. Blog post with information processed from official sites and materials, and with no additional value will not be accepted. General promotion posts about the projects are not allowed. Only promotion of new features, events and innovations of the project may be approved.
  • Promotion posts may include reports from recent conferences and social events dedicated to the project, which the author attended.
  • Project owners can submit detailed results and summaries of recent public contests and task requests.
  • Submissions should include illustration images, screenshots, links and examples. Submissions without high quality visual content will be rewarded with a lower vote.
  • Content and format of the submissions should be unique to the author. Submissions without original content will be directly rejected.
  • In the first submission of a blog posts series, it must provide a list of the following submissions and expectations of the series. Blog posts of a series must include links to the previous parts of the series.

Task Request Guidelines

Task requests should be submitted by an Open Source project owner seeking contributions to their project.

  • Submitted tasks must be explained in great detail and provide all the necessary details for it to actually be completed.
  • Every Task Request Submission post must include one task request only. Submissions with multiple tasks requests will be rejected.
  • Task Request Submissions must be related to the category where the task request is being submitted.
  • Generic Task Request Submissions, like "We are looking for contributors" will be rejected.
  • Task Request Submissions must include a means of communication for the contributor to contact the task publisher.
  • Task Request Submissions must specify a deadline.
  • If no feedback or input from the project owner was received in 2 days, moderators will evaluate the submission at their own discretion.

Tasks for Developers

Category tag: task-development

Category template: View now

Task submissions to this category must include a request by an Open Source project owner recruiting developers to the project team.

  • Submissions must include all the relevant and necessary details for the developers to contribute to your project, such as scope, timeframe, stage of development, etc.
  • Submissions must link to Documentation, Repositories, Communities (e.g. Slack, Discord) and any other relevant information.

Tasks for Bug Hunters

Category tag: task-bug-hunting

Category template: View now

Task submissions to this category must include a request by an Open Source project owner to spot bugs in their project service / system / software / website.

  • Submissions must include all available information for bug hunters to be able to begin the bug hunting.
  • Submissions must list the environments on which bugs should be searched for (i.e. browsers, devices, operating systems and other conditions under which bugs may appear).

Tasks for Designers

Category tag: task-graphics

Category template: View now

Task submissions to this category must include a request by an Open Source project owner recruiting designers to the project team.

  • Submissions must include extensive detail describing the desired outcome.
  • Submissions must include prefered file type for submission, file dimensions and any additional information necessary for the graphic component design.

Tasks for Tech Writers

Category tag: task-documentation

Category template: View now

Task submissions to this category must include a request by an Open Source project owner for assistance in updating / creating the documentation of their project.

  • Submissions must include extensive detail describing the desired outcome.
  • Submissions must include the requested features for documentations, desired length of document and any information pertinent to project documentation.
  • Submissions must include links to the tools and information necessary for documentation production and examples (when applicable).

Tasks for Data Analysts

Category tag: task-analysis

Category template: View now

Task submissions to this category must include a request by an Open Source project owner for statistical analysis of their project.

  • Submissions must specify the desired insights from the analysis requested.
  • Submissions must include specific variables and conditions to process the extracted data.
  • Submissions must include the tools and information necessary for the analysis process.

Tasks for Influencers

Category tag: task-social

Category template: View now

Task submissions to this category must include a request by an Open Source project owner for the assistance of social influencers in creating public awareness of their project.

  • Submissions must include the information and data necessary for influencers to effectively share the Open Source project.
  • Submissions must include all graphic, video and other resources influencers are expected to share.
  • Submission must detail the requirements of the visibility effort on the behalf of the influencer in terms of target audience, language and expected results.