Skip to content

Latest commit

 

History

History
403 lines (271 loc) · 31.5 KB

code-of-conduct.md

File metadata and controls

403 lines (271 loc) · 31.5 KB

ASA Stats Tasker code of conduct

Draft v2.1.1 - April 10th, 2022

Use the official discussion thread and Google Docs document for the update suggestions.

ASA Stats discussions

https://github.com/asastats/channel/wiki/Discussions

Role of a Tasker

A Tasker is a member of the ASA Stats community whose main duty is to react to the community’s requests, recording and cataloging community discussions and contributions into a tracking system for developers to process, implement and reward.

Minimal conditions to become a Tasker

Any person who can read and write in English is allowed to apply to become an ASA Stats Tasker.

The other minimal conditions are as follows:

Applying to become a Tasker

Any community member that is interested in applying to become a Tasker should open a discussion about it in the ASA Stats Discord or subreddit. After confirming the minimal condition requirements, an existing Tasker or Admin will then conduct a verification based on personal preferences.

The Process

As noted previously, a Tasker is a member of the ASA Stats community whose main duty is to react to community members' requests. A Tasker should first react as a Tasker and afterward as a community member. This means that while acting as a Tasker, a person should seek to simply migrate the community’s requests, from various social media channels, according to a specific ruleset. The following section seeks to outline this ruleset, establishing the processes and procedures a Tasker should use to perform their daily duties.

Community channels to monitor

A Tasker must become familiar with the following ASA Stats social media channels, establishing a user in each in order to be able to process requests from the community:

Types of requests to monitor

While online representing ASA Stats, Taskers should actively monitor the channels and sites listed above, scanning for community-generated messaging relating to bug reports, feature requests, and general feedback

  • Bug report: a bug is an error, flaw or fault in ASA Stats website that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
  • Feature request: a feature request is a specific idea for a new area of functionality that a community member feels will make the ASA Stats website better.
  • General feedback: the community is always welcomed to provide suggestions, personal opinions, and general feedback (ex: what works, what doesn’t work, odd user interface, etc).

Community member reactions and notation

Community members’ :this:

Community members mark a comment with :this: when they want to show support for a request they wish to be processed by the Taskers and the team. Comments with higher volumes of :this: should be interpreted as a higher priority. No rewards will be allocated for adding :this: to a request or comment. If the comment is already :noted: by a Tasker then :this: becomes optional, but may still be utilized to emphasize agreement or accentuate priority.

Platform-specific instructions for :this:

  • Discord

    • Community members mark a comment with the :this: emoji
    • If a comment's count of :this: emoji reaches 5, it should be interpreted by a Tasker as a signal for immediate processing.
  • Reddit

    • A community member creates a singleton reply comment containing only :this:.
      • Fancy Pants Editor: enter :this: by adding the command name in between two colons, then highlight it with your mouse, and click the to trigger inline code. You will see the text become blue with a gray highlight.
      • Markdown Mode: enter :this: by adding the command name in between two colons and two backticks like :command:.
    • Official marks like :this: are added by enclosing the command name by two colons and two backticks `:command:`.
    • Any other identical comments should be deleted by the commenters or admins.
    • If the :this: comment's count of upvotes reaches 10, it should be interpreted by a Tasker as a signal for immediate processing.
  • Twitter

    • A community member comments on a tweet with :this:.
    • If the :this: comment receives 15 likes, it should be interpreted by a Tasker as a signal for immediate processing.

Tasker’s reactions and notation

A Tasker’s reaction to a member’s request should adhere to the order of operations specified in the following sections.

Taskers’ :skip: notation

A Tasker should always :skip: a comment when they don't understand its meaning, or when they feel there are Taskers with a better understanding of the topic.

Platform-specific instructions for :skip:

On Reddit and Twitter, a :skip: is implied by simply not commenting; there is no need for making a :skip: comment on these two platforms.

  • Discord

    • Community members mark a comment with the :skip: emoji

Tasker’s :exists: notation

A Tasker should mark a comment with :exists: when they are certain that the same/similar request has already been issued (which can also be confirmed via Trello’s search field), or if requested functionality is already implemented on the website.

The same Tasker (or any other community member) is encouraged to provide further explanation.

Platform-specific instructions for :exists:

  • Discord
    • A Tasker marks the comment with the :exists: emoji.
    • A further explanation can be added as a reply to the original comment.
    • Other community members can confirm the mark if they want.
  • Reddit
    • A Tasker creates a singleton reply comment containing only :exists:.
      • Fancy Pants Editor: enter :exists: by adding the command name in between two colons, then highlight it with your mouse, and click the to trigger inline code. You will see the text become blue with a gray highlight.
      • Markdown Mode: enter :exists: by adding the command name in between two colons and two backticks like `:command:`.
    • The other identical comments should be deleted by the commenters or admins.
    • A further explanation can be added in the same comment next to the starting :exists: followed by a space.
    • The other community members can upvote the :exists: comment if they want.
  • Twitter
    • A Tasker creates a retweet containing :exists: and the original tweet
    • A further explanation can be added in the same tweet next to the starting :exists: followed by a space.
    • The other community members can retweet and/or like the :exists: tweet if they want.

Taskers’ :noted: notation

A Tasker should mark a comment with :noted: when they comprehend what has been asked for and are able to abstract the request into a single title sentence.

Marking a comment with :noted: signifies an obligation for the Tasker to create a card in the ASA Stats Issue Tracker under the "Incoming" list in the related board. Please see the “Issue creation in Trello” section below for more details.

Platform-specific instructions for :noted:

  • Discord
    • a Tasker marks the comment with :noted: emoji
  • Reddit
    • A Tasker creates a singleton reply comment containing only :noted:
      • Fancy Pants Editor: enter :noted: by adding the command name in between two colons, then highlight it with your mouse, and click the to trigger inline code. You will see the text become blue with a gray highlight.
      • Markdown Mode: enter :noted: by adding the command name in between two colons and two backticks like `:command:`.
    • The other identical comments should be deleted by the commenters or admins
  • Twitter
    • a Tasker creates a retweet containing :noted: - which should also contain the original tweet.

Taskers’ :na: notation

A Tasker marks a comment with :na: (not applicable) when they are sure that the request won't be implemented in ASA Stats.

Marking a comment with :na: creates an obligation for the Tasker to further explain the Tasker's/ASA Stats' reasoning for that to the commenter.

Platform-specific instructions for :na:

  • Discord
    • A Tasker marks the comment with :na: emoji.
    • The Tasker replies to the original comment with a further explanation.
  • Reddit
    • A Tasker creates a singleton reply comment containing only :na:.
      • Fancy Pants Editor: enter :na: by adding the command name in between two colons, then highlight it with your mouse, and click the to trigger inline code. You will see the text become blue with a gray highlight.
      • Markdown Mode: enter :na: by adding the command name in between two colons and two backticks like `:command:`.
    • The other identical comments should be deleted by the commenters or admins.
    • A further explanation should be added in the same comment next to the starting :na: followed by a space.
  • Twitter
    • A Tasker creates a retweet containing :na: - which should also contain the original tweet.
    • A further explanation can be added in the same tweet next to the starting :na: followed by a space.

Examples of tasker notations on different platforms

  • Discord: use the actual emojis available
    Discord emojis

  • Reddit: use the backticks around the notation
    Reddit code

  • Twitter: spell out the reaction
    Twitter text

Issue handling

ASA Stats uses Trello for issue tracking, which is then automatically synced to GitHub to allow for community viewing. The following section aims to outline the workflow required for a Tasker to handle and queue community requests for the development team to process.

Issue creation

The Tasker who has marked a comment with :noted: must also create a new card in our Trello issue tracking software.

As an initial step just prior to issue creation, a Tasker needs to first use Trello’s search field (located in the upper right-hand portion of the browser), combined with a few keywords from the request, to double-check that a related card does not already exist on one of the boards.

Each card should be created under the "Incoming" list in either the “Bug Reports” or “Feature Requests” Trello boards.

Bug Reports should be used to track reports of defects, while the Feature Requests board should be used for all other feature requests, enhancements, or improvements.

Title notation

When creating a Trello card, a Tasker should add a [LetterNumber] prefix notation to the beginning of each title to indicate the letter-based type and number-based impact of each request. Impact values may range from 1 to 3, where a [B1] bug has half the impact of a [B2], and a [B3] has triple the impact of a [B1].

For more details on types and impact levels, please refer to the table below:

Contribution Type Definition Level 1 Level 2 Level 3
[AT] Admin Task A task to produce some work that facilitates community administration across official channels. Examples: creation of contributor lists, reference checking, setup of Discord bots, cross-posting comments, or any task where the prescribed output leaves little room for interpretation. The task takes up to 1 hour to complete The task takes 1 to 2 hours to complete The task takes 4 or more hours to complete
[B] Bug Report Report of a untracked defect or unexpected behaviour on asastats.com. The bug report provides context (e.g. OS version, browser) and helpful steps to reproduce the faulty behaviour. Contributor engages with ASA Stats to provide more information and assists in testing during resolution, acknowledges when fix is satisfactory. Contributor provides deep insights that directly impacts resolution (e.g. browser side code analysis)
[CT] Content Task A task to produce written content that helps ASA Stats achieve its stated goals. Examples: an announcement in an official channel, copywriting for the asastas.com website, an email to form a partnership, or a submission to a partner site. The task takes up to 1 hour to complete. The task takes 1 to 2 hours to complete. The task takes 4 or more hours to complete.
[D] Discussion A sustained public channel discussion on a relevant ASA Stats topic, where one or more contributors make insightful comments keeping the community engaged The contribution contains factually correct information, balanced opinions, and provides a substantive amount of the discussion with several other members. N/A N/A
[F] Feature Request A request for a new feature or functionality improvement for ASA Stats. The request is specific, original, and generates sufficient support from the community (i.e. reactions and replies). The request is well thought-out, and includes a suggested path to implementation. The request is backed with a significant volume of research (UI mockups, technical analysis, etc.)
[MT] Marketing Task A marketing or PR task that helps to improve ASA Stats' visibility or reputation. The task takes up to 1 hour to complete. The task takes 1 to 2 hours to complete The task takes 4 or more hours to complete
[R] Research Research that provides new and relevant information related to ASA Stats' operations or the Algorand ecosystem. Useful research should contain original sources, and clearly explain how/why it addresses an official ASA Stats announcement or request (re: partnership, data source integration, etc.) The research takes up to 1 hour to complete, and is specific, original, and generates sufficient support from the community (i.e. reactions and replies). The research takes 1 to 2 hours to complete, and contains a thorough well-thought process and a path to implementation. The research takes 4 or more hours to complete, and is backed with a significant volume of research (research, draft proposal, technical analysis, etc.)
[S] Suggestion A meaningful suggestion for an improvement to the ASA Stats site, community or token. The suggestion is specific, original, and generates sufficient support from the community (i.e. reactions and replies). The suggestion is well thought-out, and includes a suggested path to implementation. The suggestion is backed with a significant volume of research (UI mockups, technical analysis, etc.)

If a Tasker is unsure about the specific contribution type or impact level that should be applied to a Trello card, they may open a discussion in the #tasker-discussion channel to achieve consensus.

Issue description

A Tasker should add a link to the original/first comment in the request, and quote (using > in front of the text) either all the comment's text or its relevant parts.

Example:
https://discord.com/channels/906917846754418770/908054304332603402/912101526581940334

Could you allow users to see USD value of individual assets in the table at the bottom of a person's address by hovering over? I can hover over the total algo value at the top and get USD value, but not at table below. I do see the button to switch between Algo <-> USD but would be nice to also have the hover

Issue acceptance

Bug Reports and Feature Requests boards

To accept a new issue in the ASA Stats “Bug Reports” or “Feature Requests” Trello boards, a related official adds a priority label to the issue card, and then transfers it from the “Incoming” list into the "Backlog" or "Backlog (dependent)" list as the first/top card.

A related official in this context represents a member of the ASA Stats Team, a developer in a subproject, a researcher assigned for some ongoing engine we’re going to implement in the ASA Stats website, an admin, etc.

The "Backlog (dependent)" list is used when a request depends on some other functionality or effort the ASA Stats hasn’t implemented yet.

Tasks board

Along with the two community-based request boards, Taskers should also monitor the internal Trello “Tasks” board.

Taskers may handle various tasks from both the “Incoming” and “Backlog” lists from the Tasks board, assuming they understand their meaning and are capable of fulfilling the requirements listed in the summary.

If a Tasker feels they understand what is needed to get the task underway, they should assign their name to the card, and move the card into the “In Progress” list.

Some Tasks cards may be straight forward enough for a Tasker to complete on their own with no participation of others (ex: cases where no original content is needed).

Tasks that require generation of original content, or other community feedback, should be presented to the community as an official discussion. The preferred channel for presentation of an official discussion is the ASA Stats subreddit w/ Discussion flair. After an official discussion is presented on Reddit, it should also be announced simultaneously in the other official channels: a tweet with a link to the announcement on Twitter, and a message linking to the announcement in the Discord #announcements channel. For the Twitter and Discord announcements, a Tasker will need to request assistance using an @Admin comment in Discord.

For cards that require some clarification or planning with team members, a Tasker should use the #tasker-discussion channel for this purpose prior to opening a more formal active participation discussion in an ASA Stats community channel.

Issue rejection

Already exists

If the card issue has already been implemented on the website, then the official marks the card with the "Exists" label, adds the explanation to the card's description field, and moves the card into the "Almost done" list.

A Tasker should then mark the original comment with :exists:, reply to it with the explanation copied/pasted from the card's description, and move the card under the "Archived" list.

Not applicable

If the card issue isn't possible to implement or in some other way the request won't be processed, then the official marks the card with "Not Applicable" label, adds the explanation to the card's description field, and moves the card into the "Almost done" list.

A Tasker should then mark the original comment with :na:, reply to it with the explanation copied/pasted from the card's description, and move the card under the "Archived" list.

Issue work in progress

An official starts to work on the issue and places the card under the "In progress" list and assigns him/herself to the card afterward.

Resolved issue

The official who resolved the issue moves the card to "Almost Done".

A Tasker should then mark the original comment with :addressed: and move the card into the "Done" list.

Platform-specific instructions for :addressed:

  • Discord
    • The Tasker marks the comment with :addressed: emoji.
    • The Tasker may reply to the original comment with a further explanation.
  • Reddit
    • The Tasker creates a singleton reply comment containing only :addressed:
      • Fancy Pants Editor: enter :addressed: by adding the command name in between two colons, then highlight it with your mouse, and click the to trigger inline code. You will see the text become blue with a gray highlight.
      • Markdown Mode: enter :addressed: by adding the command name in between two colons and two backticks like `:command:`.
    • A further explanation may be added in the same comment next to the starting :addressed: followed by a space.
  • Twitter
    • The Tasker creates a retweet containing :addressed: and the original tweet.
    • A further explanation may be added in the same tweet next to the starting :addressed: followed by a space.

GitHub tracking

Reported bugs and requested features list are hosted in our GitHub for the community to view:

https://github.com/asastats/docs/blob/main/reported-bugs.md

https://github.com/asastats/docs/blob/main/requested-features.md

Community rewards overview

All cards from the "Done/Deployed" list of each Trello board should be evaluated by Taskers after each two week cycle, ending on Friday at 23:59 UTC.

After the end of each cycle, a Tasker should audit the selected Trello cards to ensure that they have the proper Type/Impact + recipient values.

After each card is validated, its contents should then be added as a one line entry into the ASA Stats Contribution Rewards spreadsheet under the Ongoing Contributions tab. Each card should then be moved into the top of the Archived list in Trello.

Once all cards have been added to the spreadsheet, values should be output from the spreadsheet's Rewards by Period tab into the standardized format used in the rewards compiling section below.

The cards belonging to the official discussions or to the other sub-projects are excluded as they should have their own budgets.

Rewards processing: Trello -> Spreadsheet -> rewards list

  1. From ASA Stats Contribution Rewards spreadsheet: enter a new "Period below" header under the "Ongoing Contributions" tab - this can be cut/paste from prior cycles, with adjustments made to specify the date range and Tasker performing the work.

  2. From Trello: start from bottom of each Done/Deployed list on each board, and review each card. Ensure that it has the appropriate Type and Impact, and that the appropriate recipients are specified. As well, make a note of the Tasker that created the card (noted as person that “...added this card to incoming”).

  3. From the spreadsheet: enter in one line of data per reward recipient, filling in appropriate field values in columns A through I for: Person, Period begins/ends, Platform, Channel, Contribution (reddit, discord, or twitter link), Contribution Type, Impact level, % reward to receive.

  4. From the spreadsheet: Clone or drag the cell formula down from a prior row in column J to calculate rewards in this column.

  5. From Trello: After addition of each card into the spreadsheet, move the card from Done/Deployed to the top of the Archived list + add a comment "Added to rewards spreadsheet".

  6. From Trello: The Tasker that performs the rewards processing task for a given cycle should enter an [AT] Admin Task card to track their hours, and then enter this as the file entry in the spreadsheet + move this task to the Archived list per process above.

  7. From the spreadsheet: after all Trello card entries have been added into the spreadsheet, navigate to the "Rewards by Period" tab, and copy the output values from column D into a list in a text file.

Rewards list formatting

Each list should begin with a single-line comment at the top that begins with NOTE, and then describes the purpose of the list and the related beginning and end dates for the related cycle.

Example first line NOTE comment:

 # NOTE ASA Stats Community rewards 1/01 - 3/25

Example formatting for a Discord username and related rewards for a cycle:

 username 0.08 damo

Example formatting for a Reddit username and related rewards for a cycle:

 u/username 0.2 damo

Example formatting for a Twitter handle and related rewards for the cycle:

 @username 0.05 damo

The current minimum reward is 0.01 damo (10,000 ASASTATS), so please round up to two decimals. At the end of the list, the total should be added from column C of the spreadsheet (or by manual calculation):

 TOTAL 0.55 damo

Example formatting for a full list:

 # NOTE ASA Stats Community rewards 1/01 - 3/25
 @TylerOlthoff 0.02 damo
 AngelOfAres 0.02 damo
 CryDev 0.02 damo
 u/Algonut 0.02 damo
 u/Better-Situation-769 0.02 damo
 TOTAL 0.10 damo

Tasker rewards

After all community rewards have been evaluated and counted for each cycle, Taskers will receive .01 damo for each related Trello card they've created and handled. This card count should be tabulated during the Community rewards processing, and then submitted via the proper list formatting specified above. The Tasker that tabulates the Community rewards for a given cycle is also responsible for counting and submitting the Tasker rewards.

Admin rewards

Admin rewards are currently defined as follows for each 2-week cycle:

  • Discord Admin: 0.1 damo
  • Reddit Admin: 0.1 damo
  • Twitter Admin: 0.05 damo

The Tasker that tabulates the Community rewards for a given cycle is also responsible for submitting Admin rewards using the proper list formatting specified above.

Rewards sending

Once a Tasker has assembled complete cycle lists for Community, Tasker, and Admin rewards, they should then present the results in the Discord #tasker-discussion channel so that other Taskers may perform a review.

After the rewards lists have been reviewed by at least one other official, the Tasker should then:

  • Submit the rewards lists to the Discord #rewards-discussion channel, using ``` notation to format the list in block code.
  • Send a Discord DM to the Keeper of the Community Rewards (currently Ipaleka) to confirm that the list is checked and should be sent.
  • Post an announcement to Reddit and Twitter to publicly present the rewards recipients.

The Keeper then checks that all the numbers and formats match. If they don't match, then the list is returned back for correction.

Username public addresses verification

Before sending, the Keeper checks if the usernames are already connected with an Algorand address

For the missing connections (implies no rewards have been sent yet to that user) an Admin from the related channel will reach out to the user in DM asking for a public Algorand address.

In the case of missing opt-ins, an Admin from the related channel will reach out to users via DM to ask them to opt-in for the ASA STats Token.

Other official discussions and subprojects

Every official discussion or subproject upon completion will get a similar rewards related card under the "Done" list.

The same type of discussions like those for cycle's budgets should take place.

A formatted list having the same format should be sent to the keeper.

No community rewards will be sent outside of the process

No community rewards will be sent outside of the process defined by this document.

Tasker Verification Process

Each prospective Tasker will undergo a verification process where they will tested upon their understanding of the project, official documentation, and the related Tasker procedures. This process aims to confirm a candidate's readiness to perform all stipulated responsibilities, their adaptability for efficient handling of tasks, and allow for a demonstration of a Tasker-based skillset.

Verification Methodology

The members of the verification team may use whatever method that suits them best to verify a new candidate. This could range from engaging in a public interview, to questions posed at identifying problem solving skills, or could be as simple as thinking someone's being a good person.

Following the completion of the verification process, the prospective Tasker will enter a trial phase of 7-10 days wherein they will be charged with performing certain tasks, an outcome of which should ultimately reflect and confirm their adeptness and ability to serve as a confirmed Tasker.

At the end of the trial phase, a committee of existing Taskers will conduct a yes/no vote (majority rules) to confirm or release a new prospective Tasker.

Stipend for becoming a Tasker

If a Tasker passes the trial phase, they will be awarded a stipend of .5 damo (500,000 ASASTATS tokens).

Verification Queue

The following members of the community will verify the first batch of Tasker applicants, one at a time:

  • AlgoRhythMatic:
  • Babbexx22:
  • bear1bear2bear3:
  • Damo:
  • rach:

After the first batch of applicants is verified/rejected by these 6 members, then we should arrange the time zones and other things for future applicants.

For applicants: if these 6 don't pick you in the following two or three days for verification then you'll get another chance the next week. If you spam those 6 in DM you'll be disqualified.

Confirmed Tasker details

Discord Reddit Timezone Primary Channel
bear1bear2bear3 u/bear1bear2bear3 GMT+1 Discord
Babbexx22 u/Babbexx22 GMT+1 Discord
AlgoRhythMatic u/AlgoRhythMatic GMT-8 Reddit
MGHQ_YT u/MGHQ_YTR GMT-5 Discord
PonziCream u/AssistTraditional480 GMT+1 Discord

No punishment clause

ASA Stats has a firm “no punishment” clause that guarantees all officials and community members will be fully rewarded for their recognized contributions. If a community member is ever banned from any public channels, forcing them to resign from their official position, ASA Stats promises to never withhold contributions as a means of punishment or retribution.

Document version control

This document’s versioning uses the format: v.... The “update” version should iterate any time a change occurs that amounts to more than a simple grammatical or typographic correction. A “minor” iteration should occur when there are a sufficient amount of “updates” that require a re-sync between Google docs and GitHub. “Major” changes should be very infrequent, and indicate a significant restructuring of the document. Upon each iteration of “major” or “minor”, the lower version numbers should be reset to 0. Upon any version updates, the user should also iterate to the current date.