Create issue labels for 2016 challenge

[DragonmasterJ]

Need to create issue labels specific to the the 2016 stations, and possibly labels that relate to specific station hardware.

[ellerychan]

Can you figure out a way to attach all the Issues labeled Component-MS to the brata-hsdc/brata.masterserver repo? (And the same for the other repos.)

(Moved this from the other issue #85 where it wasn't really appropriate.)

[jawaad-ahmad]

What was the reason for this issue? What labels do we need? This would apply to the station repository if the station folks choose to have their own issue tracker. Recommend leaving alone till this is discussed with them.

[jawaad-ahmad]

Speaking of labels, I think we need a discuss or discuss at next meeting label. It would be nice to track the ones that we're waiting on group input so we can bring them all up when we get together.

I'm referring to the ones such as when the MS folks needs to speak to the Station folks.

[ellerychan]

I my concern was addressed by our decision to link the old issues, and is captured adequately in our Process.

I like your discuss label idea.

[jawaad-ahmad]

Added a discuss internally and a discuss externally labels for now and updated the Process page.

[jawaad-ahmad]

For the MS, I recommend additional labels to break down into the apps discussed last week:

• ms-backend
• ms-frontend
• ms-scoreboard
• ms-mobile

Thoughts?

[jawaad-ahmad]

Also in general do we need one for something like design required to make sure we don't move forward in the wrong direction for implementation in certain key cases, or is that too much for us?

[ellerychan]

Whatever labels you want. I just pushed an initial bit of code, so you might want to modify the labels to match what I named the apps:

Old	New
ms-backend	ms-dbkeeper
ms-frontend	ms-piservice
ms-scoreboard	ms-scoreboard
ms-mobile	ms-teamcentral

[ellerychan]

Question: When should the question label be used, and when should discuss internally be used? They seem similar.

[jawaad-ahmad]

Maybe they are. I believe the question label was given to us when we created the issue tracker.

I'm fine with applying the question label to all discuss internally issues and then removing the discuss internally label from both repos if there are no objections.

[DragonmasterJ]

I think the description of this issue needs to be updated a bit now that the issues are specific to their repos and deviates from my original thoughts with this issue. I was thinking since a lot of the station code is going to be reused, it may be appropriate to add some labels for lcd screen station, light sensor station, etc. That is now left up to the station teams, this issue should be more general, like each team make their appropriate labels for this year and general labels.

[jawaad-ahmad]

We've got our labels for the MS tracker. The other teams can create labels for their components as they feel best to organize their issues.

Besides we already have station labels in this repo from last year--HMB, CTS, and CPA. There are already issues tagged to these labels that still need to be worked. The @brata-hsdc/station-devs need to figure out which station this year maps to the corresponding station last year.

I recommend renaming the station labels rather than creating new ones so that all tagged issues go to the new labels automatically. The labels and issues would need to be recreated in the station tracker to remove them from this one.

[DragonmasterJ]

Sounds good, with that in consideration, we'll leave the description of the issue as is, since it still applies to the station teams.

[jawaad-ahmad]

I don't think there's any reason to keep this issue.

Need to create issue labels specific to the the 2016 stations, and possibly labels that relate to specific station hardware.

This will be done as-needed; no need to track via an issue unless discussion is needed, and I think we've discussed this above.

Can you figure out a way to attach all the Issues labeled Component-MS to the brata-hsdc/brata.masterserver repo? (And the same for the other repos.)

Done via manual brute force. Not the most interesting, but it was the most effective. Actually it was good to go through each one one-by-one. I was able to write something up for a couple and resolve them along the way.

We still have the item open regarding question vs. discuss-internally. I think we can get rid of one of them. I'll remove discuss-internally and attach question to all impacted issues now.

[jawaad-ahmad]

Done. discuss-internally removed, and set the color of discuss-externally to the same purple color as question.

[ellerychan]

I vote close this issue.

BTW: Closing issues seems to be a weak spot in the process. Does someone unilaterally decide to close it? Do we take a vote? Do we get a concensus by some other means?

[jawaad-ahmad]

First of all, you, me, and @DragonmasterJ are currently owners of the organization, which means we probably see many more buttons on here than the average developer. Starting out on GitHub, I'm not too thrilled about this because I can't gauge a normal developer's experience if I'm roaming around the site with extra permissions.

So it's possible we see the ability to close issues but most other folks won't.

Code changes or not, I propose we follow the process outlined in the Quick Start even for issues such as this, meaning we set the state to state:3-resolved and leave it there.

In the case of pull requests with a properly-worded comment, the issue will get closed automatically when the branch is pulled to the default branch.

We can leave these issues in the resolved state and clean them up periodically when we meeet face-to-face. It'll give anyone a chance to come back during that time and reopen an issue by simply changing its state from state:3-resolved back to state:2-in-work.

That's what we did last year. Every so often, we went through the issues and decided what was safe to close and what we should leave open a little bit longer. As long as they were in the resolved state, they didn't bother anyone.

Thoughts?

[kjones27]

So, back to the original question. Are we keeping the station labels as is? For instance, I'm working on Return to Earth. Should I 1) create a new station-rte label, 2) use the existing station-cts, or 3) rename existing station-cts to station-rte? For my station, in particular, it's a update to last year's CTS. But, I don't know if all of this year's stations have a complement from last year.

[jawaad-ahmad]

I think renaming the current station-cts label the station-rte would be the best way to go unless anyone feels differently.

We probably already have some bug fixes and other issues tied to it, so renaming will seamlessly carry them over to this year's station transparently.

Thoughts?

[kjones27]

Okay, I renamed station-cts to station-rte. It's easy to undo, if others feel differently.

[DragonmasterJ]

I think that's a good way to do it. We don't have the mess of adding tons of labels with each new competition, and tracking multiple labels for each hardware type.