search

MetroCS / redistricting

Experimentation with geopolitical redistricting
GNU Affero General Public License v3.0
5 stars 75 forks source link

[UserStory] Further Documentation of Contibution Conventions on Contributing.md #200

Open jarell38 opened 11 months ago

jarell38 commented 11 months ago

User Story

Essential components

Story

As a maintainer I want the Contributing.md file to provide a more robust description of procedures needed for a new contributor so that a new maintainer can have a better idea of how to contribute to the project

Acceptance Criteria

(Rules or scenarios are acceptable formats.)

Supporting Information

Related to Epic #4 there is a lack of information in the documentation on how to begin contributing to the project and the processes that are in place for being assigned to issues, creating new issues, and the overall workflow in place for the project or lack thereof

CoffeeTulip commented 11 months ago

Im going to add some more clear and concise steps to installing ant and work on making the build instruction more clear for Mac including: command line lines for examples website link to respective appropriate websites step by step instructions and 'prerequisites' for what you need installed to build

jody commented 11 months ago

Thank you for opening this issue!

Is this related to Epic #4 and/or Epic #80?

Given the different items addressed in the Acceptance Criteria, this seems better to be broken into three individual User Stories / Issues.

The Acceptance Criteria need to be objectively evaluatable in the product. For example, the meaning of "better" is not quantifiable or objective. Please rewrite the acceptance criterion for each to have specific measures that can be used to determine if the issue is resolved.

Was the intent of Acceptance Criterion "Rule 3" to have the same information reproduced in multiple placers in the repository? (If so, that opens an opportunity to introduce internal inconsistency which is avoided by disallowing redundancy.)

jarell38 commented 11 months ago

Okay thank you for the feedback

jarell38 commented 11 months ago

Thank you for opening this issue!

Is this related to Epic #4 and/or Epic #80?

Given the different items addressed in the Acceptance Criteria, this seems better to be broken into three individual User Stories / Issues.

The Acceptance Criteria need to be objectively evaluatable in the product. For example, the meaning of "better" is not quantifiable or objective. Please rewrite the acceptance criterion for each to have specific measures that can be used to determine if the issue is resolved.

Was the intent of Acceptance Criterion "Rule 3" to have the same information reproduced in multiple placers in the repository? (If so, that opens an opportunity to introduce internal inconsistency which is avoided by disallowing redundancy.)

Changed the issue to only a single part of the original issue and hopefully cleared up any vague wording

jarell38 commented 11 months ago

If the issue is sufficient enough to be added to the to-do list I would like to assigned to this issue

jody commented 11 months ago

The project has documented specific stakeholder types: https://github.com/MetroCS/redistricting/blob/main/Vision.md#stakeholder-identification Please identify one of those roles or explain why a new type of stakeholder is required.

Unless you have an estimate of effort that is much smaller than my estimate, this seems like it is an epic rather than an actionable user story. (That seems to be borne out by the generic nature of the issue title itself.) I will add the "epic" tag and am open to removing it based on an estimate from you.

As an "epic", this is best broken down into several small and simple User Stories that collectively address the multiple goals articulated.

jarell38 commented 11 months ago

okay I think I have a better idea now as to what constitutes an issue vs. an epic so I'll make new smaller issues referencing this epic