Live data from Hacker News

New GitHub Issues Beta

github.com

171–180 of 223 posts

Re: New GitHub Issues Beta

#171

> Bored of boards? Switch to tables. I love this. I don’t know why the “agile board” became a thing. To me it always seemed like a poor way to visualize what is a list of items. My problem with agile boards is that they place tasks into separate columns to denote the task state, which often cuts off the task description (and can require a lot of horizontal scrolling). It also prevents using columns for other fields l…

My take on the background of why it became a thing:

I think the idea with boards is that the (artificial) constraints of the medium are helpful in certain team configurations. As far as I'm aware, boards are most strongly advocated in Kanban, where there's a hard limit on WIP -- so having a board where you actually cannot have more than 10 items in your backlog before everything goes to hell is a feature not a bug.

In Kanban, it's really important to be able to see at a glance, where your WIP is in the pipeline, e.g. you don't want to start a new task when there's a huge backlog of tasks waiting to be validated. In a table, you lose the ability to get a birds-eye view of the sprint status.

Most teams aren't doing Kanban though -- so I think it's plausible that most teams will find a table view more usable/efficient.

Re: New GitHub Issues Beta

#172

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…

The custom scoped labels in GitLab are very nice, and I found great uses for them.

I threw away all the default labels for now, and juggle just two custom sets of scoped labels: `urgency` and `kanban` (which column on the board).

All `urgency` labels are color-coded (red, orange, green, blue), and also ordered (for when viewing in the Issues List, rather than on the Board). I was using only the `urgency` labels before I added the Board and `kanban`.

`kanban` labels are all gray, and tie in with the Closed property of an Issue: non-Closed `kanban` labels can be `backlog`, `waiting`, `doing` (each of which have a Board column); Closed can be `done`, `abandoned`, `duplicate` (all of which are in the Closed column of the Board).

I'm mostly liking this, though still missing Gantt models and views sometimes, even in very dynamic/agile/responsive/reactive tasking. For example, even just yesterday, a few Blocked-by relationships are not obvious on the Board, as they're piling up in the `kanban::waiting` column. (And finishing those tasks was an extra relief, so the Board was back to intelligible.)

Re: New GitHub Issues Beta

#173
they built notion boards into github. nice work! we've been using notion for our product work and it's been very flexible and powerful, but I do miss having the code and issues living together.

Re: New GitHub Issues Beta

#174
post #45

Earlier quoted context omitted.

You can use projects for this (it is what we do). Create a project for the org where non business people can add issues/todo's to and then developers can click "Create Issue" on them and create a more detailed issue for the appropriate repo.

Those are text-only and don't support comments, labels, statuses, markdown or basically any of the other things that might make issues useable. There are issues that apply to a whole org. There are "non business people" that know how to add context to an issue but not exactly in which repo it might fit best. "Notes on a board" is not a replacement for org-level issues.

We encountered the same issue, but it seems to be only for projects at user/organization level. What we do to work around this is to create a new repository used solely for projects.

By doing so, you can create and put the issues in the project board, and apply labels to the issue (which does show up in the project board). The long details can be put in the issue description, and it can be linked to other repositories nicely as well. The trick really seems to be to not use user/organization project, but (dedicated) repository project.

I wish they documented this better or improve it somehow, but hey! I guess they were working on the beta issues board/table which is also pretty sweet!

Re: New GitHub Issues Beta

#175
post #8

Github should first fix that it displays "issues" of a repository instead of useful info when exploring https://github.com/explore Why would I want to see issues of a repo I have no clue about? I am there just to discover a new repo.

I've noticed since Microsoft acquired Github, the "explore" tab has been more and more useless. It's been months since it displays me the same repositories, and significantly less than before. I don't know if it's related, but the timing is suspicious.

Explore has been… unuseful to me for years before MS bought GitHub.

Re: New GitHub Issues Beta

#176

Earlier quoted context omitted.

They mostly don't. Once you have Jira, you have Confluence, then Bitbucket. That many less contracts to manage.

Yeah. We used to pay for GH Enterprise and run Jira/Confluence/Bamboo/etc/etc. Then we switched to BitBucket Server because it integrates better and cost a lot less, plus GH Enterprise was a weird black box VM back then that we had to hack into to make work for whatever reason. I couldn't point you to anyone who likes BitBucket Server, but as long as you're on the CLI and don't have to use the terrible web UI too muc…

I much preferred Bitbucket Server to Bitbucket Cloud. For context, Server is an entirely independent codebase to Cloud (not even a fork, just completely separate products).

Re: New GitHub Issues Beta

#177

Earlier quoted context omitted.

Why not just tag it with separate labels? For that example, tag it with ui, app, and android. Then search with ui and app labels?

For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.

hrm.. I guess I could see that being useful in some cases. It might make discovery a little harder for someone that doesn't know the hierarchy, but I could see that being useful for people that know the hierarchy in an org that has a massive amount of stuff to label. I guess I just like key/value tags better than labels to organize and filter through data. They seem a little more self explanatory and I think they obviate the need of a hierarchy in the tag key naming.

Re: New GitHub Issues Beta

#179
post #127
post #23

I am longing for the day they deprecate Azure Devops and merge it into GitHub Enterprise. This is the only way I’ll ever get the ability to work with GitHub in my company, which has a much superior UI/UX imo.

Azure DevOps is quite a bit more advanced than GitHub. Is there a feature that GitHub has that is missing from Azure DevOps? UX is very subjective and while DevOps is not perfect, I don't find it straight up horrible. It has way more features that need a place in the UI. Plus it's lightning fast compared to JIRA.

Azure DevOps seems to be full of interface bugs and gotchas, and the UX is a whole magnitude poorer in execution compared to GitHub. Also the whole Microsoft SSO flow gives me serious problems when switching between my 3-4 Microsoft accounts, and means I have to keep opening up incognito tabs. GitHub organizations are so much better at this.

And does nobody else find the URL schema of Azure DevOps highly confusing? You seem to be able to load up the same dashboards from 5-6 different URLs, and some days certain URLs don't work and others do, and I just have no idea where to land for the front page half the time! The only way I know how to quickly get to my org in Azure DevOps is by the several shortcuts on my desktop. If I lost it, I'd be screwed.

And I find it so jank that you have to go into a completely separate area and click through several tabs with page refreshes to find the ticket list for a project, and even then the backlog view is not intuitive to use.

Re: New GitHub Issues Beta

#180
post #138

Earlier quoted context omitted.

Kind of an XY problem to me. The backend and frontend should be in the same repo unless you have an excellent reason for one to be in a separate source repository. The rifts are more numerous than just ticketing on GitHub issues, imo.

The monorepo question is not a question with a one-fits-all answer.

This isn't a mono repo, it's a set of associated code. If you have a front end and backend that are tightly coupled they should be in the same repository.
Post reply on HN