Skip to content

Issues @ Development Guide:

When creating an issue please ensure the following is done correctly when submitting:

The Title:

  • If possible please make the title no longer than 180 characters (exc spaces).

The Description:

The Template should be automatically chosen (Fill out both Sections).

  1. Summary Section:
    • For a Bug Report include: What's wrong, Steps to Reproduce, Guidance on how you think it should be fixed and photographic or video proof.
    • For a Feature Request include (This includes adding new commands): The function of the feature, How would it be implemented and if needed what external modules (packages) are needed.
    • For QOL Enchancement or Improvement include: What feature(s) are you improving, How would it be implemented and the benefits and disadvantages of it.
    • For a Merge of Commands include (Brave Bot Only): What commands you are merging, How would it be merged and the benefits and disadvantages of the merge.
    • For a New Post / Guide include: Brief overview of what will be written (do not leak any content or etc).

Labels:

  • Please add the correct labels to the issue/suggestion/feature idea/proposal.
  • There is no limit on how many labels you should add but please be mature.
  • A Priority Label is requried on all issues. If unsure put the n/a priority label.
  • Click Here to see List of Avaliable Labels

Priority Labels:

Priority labels are too determine how quick the overall response to the issue should be. Immediate Priority being the highest (only for urgent and breaking issues). Most issues fall into either Low or Medium Priority. Please note that your priority can and will most likely change if the issue is open for a long time.

  1. Low Priority
  2. Medium Priority
  3. High Priority
  4. Immediate Priority
  5. N/A

Extra Guidance:

  • Anything GitLab Related should use the Medium Priority Label.
  • Anything Database Related (Espically bugs / errors) should use the High Priority Label.
  • Any Bug Report that is minor: typos, incorrect url, incorrect emoji/graphic(s) or etc should use the the Low Priority Label.
    • If the typo or etc can be seen alot or etc, please use the Medium Priority Label.
    • Database Issues or Bugs or Medium / Major Logic Errors/Issues should use the High Priority Label.
  • Improvement / QOL or Expansions issues should use the Medium Priority Label.
  • Performance / Speed Issues should also use the Medium Priority Label.
  • Documentation related Issues should use either the Medium Priority or Low Priority Label(s).
  • If any code change requires documentation editing, please add the Core: Requires Docs Edit(s) label.

Core Labels:

Shows weather it is GitLab related, Database Related, or weather it is a Bug Report or a Suggestion.

Code Labels:

Should highlight what part of the Code needs fixing/improving/updating/added.

Feature Labels:

For Brave Bot, if you are updating or fixing a system that has it's own feature label (Example: ProButtons) you must used the respective feature label. If this change requires documentation editing, please add the Core: Requires Docs Edit(s) label.

Milestone(s):

Most issues that are not a top priority should be in the Backlog Milestone. If the merge request for the issue is complete and an upcoming update milestone is avaliable. Please move it to the respective milestone and await for approval.

Info

The milestone represents which update the issue (whatever it fixes or releases) is being released. We tend to plan updates months in advance per standard for development of any project.

Creation Guidance:

If you are planning one of thing(s) listed below:

  1. An Update
  2. An Hotfix (A Hotfix does not require a Milestone)
  3. Rewrite (Requries approval from CEO)

Then you may create a project milestone.

Info

  • To create a Project Milestone you need the Reporter Role or Higher.
  • To create a Group Milestone you need the Developer Role or Higher.

When creating a Milestone. Please look at the guidance below:

  • Title:
    • For a Update, set the Milestone to the Update's Name. (The Update's name is normally set by someone from IndiSpark)
    • For a Hotfix, set the Milestone to Hotfix {date}. The date should be the targeted release date for the Hotfix. Update if delayed.
    • For a Rewrite, set the Milestone to the area being changed and then "Rewrite. Example: Fun Unit Rewrite
  • Description: Not requried but just outline what the milestone is for and who is leading it.
  • Due Date & Start Date: Not requried but if an update has a set date for release, then please set the due date accordingly.
    • Setting a start date is not requried at all.

Closing a Milestone:

You may close a milestone if it has either:

  1. Reached 100% and has been released.
  2. The milestone has been abandoned.

Warning

Do Not Delete/Close the "Backlog" Milestone.

Backlog Milestone:

Issues that can not be assinged to be an update, hotfix or rewrite should be assinged to the Backlog milestone. What does this milestone mean for the issue?

  • It means anyone can work on it when they have free time. (Do not have any assinged issues)
  • The idea or etc is not a priority for IndiSpark. (Can be changed)
  • The idea could be released in any update. (If it can't, then it must move milestones)

Info

Bug Reports that are not unconfirmed should never be put in the Backlog Milestone.

Linked / Child Items:

  • If needed please add it where needed. (Can be done post submission or by going to the related issue, clicking on the 3 dots and selecting "Create Related Issue".)
  • Child Items are issues that contribute to the issue's completion. (All fields that are normally required for an issue are required for a Task)
  • Linked Items are issues that are related to the issue but do not affect completion/release. (You can link issues from the Docs with Brave Bot issues)

Assingee:

Assign the Issue to yourself or to anyone who wishes to complete the Issue. If no one wants to please leave it un-assigned.

Disucssion:

When discussing about a recently opened issue or etc. Please ensure the conversation is on-topic. Topics that should be conversed:

  • How to implement? (For new Features / Suggestions only)
  • How to fix? (For bug reports, errors or etc)
  • Does it comply / follow our values and the OSS Values?
  • Does it follow the Goverance and the PoP.

Warning

When discussing on GitLab you are bound to follow IndiSpark's Policy of Public. Click Here and GitLab's Policies.

Discussions when updating PoP:

Post Issue Opening:

Once an issue has been opened regarding the PoP, the following must happen:

  1. Consultation
  2. Compilance review with OSS Values and OSS Goverance Values & Fundamentals.
  3. Public Review & Feedback.
  4. Final Decision.

If it is a bug-report then the following must happen:

  1. Checks on weather the bug actually exists.
  2. If needed, a consultation on how to fix it without harming PoP intgerity and its compilance with OSS Values.

Guide on adding new rules:

Thinking about adding new rules or etc? Well before creating an issue do the following:

  1. Check if it follows OSS Values and Goverance Values / Fundamentals.
  2. Check if there is already a rule about it.
  3. Is it really needed?
  4. Will it positively impact the community and integrity of the policy.