Handling Bugs & Features Requests with Github Projects

ubernaut

@lafayette this all looks pretty good to me happy to help on 2 and 3 if i can

LaFayette

@ubernaut Excellent, let me know if you don't have enough permissions on the project to create cards & manage issues.

Sounds like our next steps are to:

create another project for feature requests
organize/add cards

If things work out well, we'll then want to update public documentation:

github issue templates
forums (categories & any pinned posts)
website: https://triplea-game.org/
README / how-to contribute

ubernaut

@lafayette not rly sure i understand the project/card system (it def looks good) but will try to check it out asap and get back to u

TheDog

@LaFayette
I have used Trello before.

Please setup a project for feature requests.

I have a few feature requests to add to it, and I will go back over the most recent Feature Requests & Ideas forum posts and link them to the project cards.

Also, I will try and rank the top 10 feature request.

So I will be your Project Administrator.

EDIT: To qualify I will be your Feature Requests Project Administrator.

Panther

@LaFayette

@thedog said in Handling Bugs & Features Requests with Github Projects:

So I will be your Project Administrator.

... what I volunteer to be regarding Rules Issues.

So do we need a project for rules related issues - or do we add them to the Problem Tracker Backlog, together with other technical topics?

LaFayette

Feature Request board is started:

https://github.com/orgs/triplea-game/projects/9/views/1

LaFayette

Some Thoughts on the Project Board Organization and the goals of the project boards

How we organize the two boards, feature requests & problems is a bit of an open question.

Needless complexity is not going to help us, perhaps we should stay firm in keeping in mind what our goals are. Essentially we want to organize the issues/topics so a person (developer) does not have to dig through very long lists of many items & generally does not need to spend much effort to find something to work on.

A next important goal, if not more important, is enough organization that maintainers can feel like the various lists are not just a mess, that the important items are indeed visible and easy to see.

It would also be great if average players can look at the lists to see where things are. I think that is a stretch goal.

With respect to these goals & priorities - we need some organization, we need some prioritization, just enough to make sure that the top important things are obvious.

LaFayette

@Panther it might make sense to split up the 'problem tracker' columns a bit. I'm a big fan of stack ranking items too, take a card and compare it with other cards to say whether this one should go before or after another card. Priority of bugs/problems should generally be a calculation of impact multiplied by frequency. Rare bugs that kill/crash games, or very frequent bugs are items to go to the top of the list.

With that said, we can use columns to help organize items (rather than using labels, or do both). For example, a column of 'rules problems', and perhaps another for 'fix sooner' to represent the high impact problems that are not rules problems.

@TheDog / @ubernaut , we might want to do similar for feature requests. Things like columns for 'game play efficiency / quality of life', 'map XML features', 'UI enhancements', etc.. That level of organization could very well be overkill and needlessly complex.

When there is a lot of questions on how to do taxonomy of issues/tickets, I often like to try and simplify it to: "fix sooner" & "backlog", where the backlog is organized such that the top 3rd is roughly equal priority, and bottom two thirds are mostly unorganized and are more a big list (where if that top 3rd is worked down, then items from the big list can then be pushed up and organized a bit more).

So, lots of "thinking out loud" ideas here. I think we need to try to start moving items on the boards. Once we have stuff there, it might be easier to see a logical way to sort them. Starting with less I think is going to be more. Perhaps starting with just a "fix sooner" and "fix later" list is good. Going more detailed, to capture different types of work items, could be useful too (but at risk of unnecessary sorting/complexity0

ubernaut

@lafayette sounds good to me

LaFayette

To be a bit explicit, and a small role-call:

@Panther is going to be organizing the rules related topics.

@TheDog more focused on the feature requests

@ubernaut potentially helping on either/both

We might still need some more help on organizing the (non-rules related) bugs/problems. Overall, perhaps we're already off on a decent start now

ubernaut

@lafayette so i look this over again still not sure i understand what i'm supposed to do but maybe it will make sense once i try it

Panther

@ubernaut said in Handling Bugs & Features Requests with Github Projects:

@lafayette so i look this over again still not sure i understand what i'm supposed to do but maybe it will make sense once i try it

I can offer you to guide you a bit through, once I find some time ...

TheDog

I have enter my top 10 Feature Requests and will hopefully keep that topped up with a curated list for the Devs to pick from.

Currently it looks like this
https://github.com/orgs/triplea-game/projects/9

Not sure if people have access to that link so ...

I have ordered the two columns with Top ordered
Top=Hard/Long -- Bottom=Easy/Quick
hopefully that will help a Dev with limited time.
.
Currently even I cannot access that link from here
https://github.com/triplea-game/triplea/projects?query=is%3Aopen

As only 2 Projects are listed, @LaFayette please fix

LaFayette

@thedog The difference is project can exist at an "organization" level and also at a "repository" level.

https://github.com/orgs/triplea-game/projects/ vs https://github.com/triplea-game/triplea/projects

The repository level projects came first, hence there is that history behind them.

I think we probably should prefer org level projects, but I don't have a very strong opinion on that per se. It is confusing though that projects exist at different 'levels' like that. (In part it's an interface issue, should be more clear what is what)

With that said, no real recommendations here, just hopefully that clarifies what is going on. Happy to tweak things as would be helpful.

TheDog

@lafayette
As GitHub is already hard to navigate for most users, including me, I would prefer if the projects could have a pointer/view to where it currently is now, just like the current problem tracker does.

That way when a new user of GitHub looks to get

Releases - download manually
Raise an issue
Look at any Project its all there, or appears to be there

https://github.com/triplea-game/triplea/projects
Appears to more for us users

and the 1st link appears move for Devs, well thats my perception.

LaFayette

Of note, I see that the 'problem tracker' project appears in both the game-client repo (specifically, triplea-game/triplea) and also at the 'org level', at 'triplea-game'.

There's no connotation for me that one is geared for dev's vs users. To some extent, they are geared for both I would say, perhaps more dev's as ideally someone would use the project board as a working board.

Releases - download manually

With luck this is going to go away to some extent. The release model changing will make the latest release available from the website for download.

I would prefer if the projects could have a pointer/view to where it currently is now

I don't quite understand what you mean here. Would you mind clarifying?

TheDog

@LaFayette
Yes I would like it to be like the 'project tracker' project to
appear in both the game-client repo (specifically, triplea-game/triplea) and also at the 'org level', at 'triplea-game', just like the 'problem tracker' project does.

LaFayette

@thedog Found it - there was a "link project" option. Should look good now

It looks like Github has changed projects a good bit from a couple years ago. Projects in github used to be repository level items (repositories are owned by organizations). Now projects look to be true organization level items with "links" to possibly zero or many repositories. The links create the previous behavior and adds some additional flexibility.