New GitHub Issues Beta | Hacker News Reader

New GitHub Issues Beta

github.com

599 pointssplitbrain212 comments

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 issues.

One of the things i still notice about the boards is that it is created on the basis of status. Gitlab's boards are created on milestones/status...or LABELS. https://docs.gitlab.com/ee/user/project/issue_board.html#org...

Most importantly, dragging tickets across boards will change the labels. This is far more powerful than just hardcoding them on statuses.

This seems to be covered by the new ability to extend issues with custom fields.

not really - u can have multiple labels for an issue. but one value for a custom field.

that's why the scoped/hierarchical stuff start becoming powerful for issues.

Gitlab had the right insight here.

Scoped labels are the primary thing keeping me on GitLab

Wild, I just went through the pain of automating all my org labels today and it was a huge bummer to not have scoping. I'm doing "Type: $var" etc but I know it'll look terrible compared to scoping.

Going from Gitlab to gh has been interesting.

For anyone unfamiliar, example; https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu...

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.

"UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works?

It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a different search. Having the platform last seems strange to me, though.

my apologies.

Its the hardest thing in computer science - "Naming Things"

Yeah, often I get into a problem where I wanted to have a hierarchical tree to organize my things and then later I wanted to somehow connect nodes from different branches in some way. I guess you could always have `ui::app::android ui app android` if needed

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.)

It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.

Where did you end up?

We ended up using Linear and are very happy with it. Their approach is also low-level enough to be useful. Best Github integration I've seen, too.

I use Linear too and it's great. Awesome keyboard shortcuts, easy to use UX, super minimal and quite fast.

It feels like this is intentional on GitHub's part. To their credit, they do call it "Project planning for developers." That said, I agree that they are missing a huge opportunity to move Issues outside of the current 1:1 with a repository.

Very much agree, most projects I work on these days have components in multiple repositories and trying to coordinate work among them is challenging. We use Github Issues as a source of truth but have resorted to using third-party software on top of them to help get a bigger-picture view. Currently we're using Codetree: https://codetree.com/

Maybe Github Issues is not supposed to work as a support ticketing system? You are allowed to move issues between repos, so in theory you could create a dummy repo where users can add issues, and then those issues can be moved to their appropriate repo.

I think Microsoft does this with their .NET ecosystem of repositories, issues, and projects.

What if I want to define a new feature that has both backend and frontend tasks, and have separate repos for the FE and BE? Which repo do we create the issue in?

Neither, you should have a third conceptual tool to encapsulate the overall product, then once you have a feature spec, you cut tickets for the subcomponents.

Depending on the API complexity, I personally would either define the spec as a PR to our API doc repo, or define it as part of the backend task.

If I have a third tool, I might as well use that tool for all my issues anyways then? Especially when a tool like Linear can integrate with GH anyways.

I've actually been experimenting with something similar to what adrianpike describes. Basecamp is home to all higher level product/business stuff. In part, that's because everyone in the business has access to Basecamp and uses it on a daily basis.

Concrete development work gets put into GitHub Issues. Most people on the business side don't have access to GitHub and wouldn't be comfortable with it. Smaller stuff may not get a GitHub Issue. It may just live in Basecamp. Technical stuff that the business will never care to see may only live in GitHub.

It's a new process I'm experimenting with. We'll see if it ends up being too disjointed.

indeed, that's where we ended-up, by using Linear which provides the layer of abstraction. it's just disappointing because it's a long-standing issue, and relatively easy to solve (based on the fact many 3rd parties have).

Presumably you would want a professional engineer or project manager to triage and curate issues long before they end up on a developer's actual task list, in which case it really wouldn't matter.

You'd group the repos together in an organizational project and open the issue there.

https://docs.github.com/en/issues/organizing-your-work-with-...

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.

Either one. You'll eventually open an issue on the other repo too and link them.

For me in Gitlab, you would create an epic (if its a large feature) and then put all of the tasks as their own issues in the respective repos.

I think it's honestly pretty far to do this but never end up moving the issues - we have some repo-of-relevance labels we use to indicate ticket applicability but otherwise our issues just continuously pile up in the same repo.

Commenting only on the "support ticketing system".

Just in case it did, it would radically deprecate a bunch of tools and simplify life of small dev teams.

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.

Yes, that's exactly it. Project boards, spanning multiple repositories, have been on Github for years; seems by the comments in this thread that Github isn't advertising them well enough!

Wow, we haven't used Github for years because it was missing this feature. I saw the new beta and looked if they supported cross-repo issues, and was disappointed. Turns out, they do? They just make it very hard to discover? Odd. Seems like low hanging fruit to fix.

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!

The new project experience allows you to track issues that are in different projects, prioritise them alongside each other etc. I work at GitHub where we've been trying this out for a while and it's working pretty well so far for a bunch of the projects I work on when you need that cross-project visibility and co-ordination.

What I need:

1. Issues that can be linked to other issues (regardless of repo), i.e. local issue blocked by remote issue

2. Projects that can contain issues from multiple repos, even a mix of public and private repos

Please say this is now possible, otherwise we too are looking at Linear, Jira, etc when we'd like to be looking at Github.

It is indeed now possible. Give it a try and let us know what you think.

Can projects now contain issues from multiple _orgs_? I've had worked on things that spanned orgs before, and as far as I know projects couldn't handle that.

I'm really glad subtasks is now a thing!

For #1 hasn't this been possible for a long time via including the issue linking text: OrgName/project#12345 in either an issue body or comment text - or else including it in a commit message?

Due to #1 our org created a no-code repository for hosting all of our issues and it's worked out pretty well - PRs reference the ticket using the issue linking text above and it all works pretty seamlessly - the only slight hiccup is that we only write issues in the no-code repository since splitting issues across repo would cause milestoning issues for releases.

I think a lot of these problems would be solved by just adding an "Issues" tab alongside the "Projects" tab at the organization level - with all the features that go along with that (Milestones, labels). Then you could have issues at the organizational level, separate from repositories, and that would allow you to better deal with stories spanning multiple repositories. Especially since these updates (which are fantastic by the way) seem to be adding support epics and the like, it wouldn't be unreasonable at all for epics to span multiple repositories (Frontend, backend, infrastructure or multiple microservices in a multi-repo setup). Conceptually, putting those issues on one of those repositories feels wrong. Putting them on the organization is much clearer.

We seem to be using Taiga for this reason, but as a non-technical user doing some coding in our repos from time to time, I'd love to use Github. The UX is better, and having everything in one place feels best

We addressed this by moving to a monorepository for the organization.

Obviously, this doesn't work for everyone, but in my experience it is really amazing when you can pull it off.

This X 1000.

Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work.

More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.

GitHub issues should not be used by non-technical contributors though (imo)

I dunno. From a UXR perspective, issue tracking is frigging amazing.

You can learn so much about what the user experience is from just having them tell you what's wrong. It's a real bummer though: most of the people responding are about as far removed from UX researchers as you get: almost no ability to put themselves in the shoes of others.

I agree. But many projects redirect users to Github for issues and SO for documentation :/.

I love having our less-technical team members on GitHub. We post loads of screengrabs in issues and PRs, discuss changes and wording and it keeps everyone in the loop.

I really wouldn't want to go back to using a separate to like Jira or Trello.

Non-technical users are often burdened with the responsibility of project planning and timelining - in this case seeing how many tickets are closed and where your team falls relative to expectation can be invaluable.

I disagree. Everyone should use Github. It's free, and paid versions are less than half the price of any other paid app there is.

Just make a repository named "jira" or "support tickets" and move forward, no?

Product team shouldn’t understand the product sounds like a recipe for failure to me. The product team actually should have a good idea of which component does what and be able to identify where the defects and opportunities lie. If they don’t then that’s a communications failure.

This is the biggest complaint I've heard from company, and the reason why most reject using GitLab or GitHub for issues.

It works great for FLOSS, but not so good when the people opening issues don't access repositories.

In case the GitHub Issues team is still looking here, I have a request! Can you put the name of the commenter somewhere besides just the name field in the email from? Currently it's something like, Poster Name <notifications.github.com>, but that means you can't tell who the poster was from the email content itself.

I use Apple Mail and have a contact for GitHub since that provides benefits like an avatar, easier search, etc, but now the contact clobbers the name field and I just see every email from "GitHub" with zero indication who wrote the comment.

"it's just a spreadsheet, and [view X] is a filter on that sheet" is a nice mental model. I've had lots of managers organize stuff in google sheets and then copy to [task manager X] simply because it's easier to think about - they'd probably love this. I certainly would, vs Jira's massive "everything is custom UI / a unique concept" mess.

Their spreadsheet implementation looks really nice (from the screenshots). Can't wait to try it.

Our primary interface at Streak is a spreadsheet. It looks simple to build but we've invested (and continue to invest) a ton of engineering time to making it great. Users love the interaction model like you said.

Their spreadsheet view reminds of Airtable a bit, or the notion-like tools that are very popular right now.

Yes! We use a Google Sheet to track subtasks of issues. Now maybe we won't have to. Breaking every subtask into its own issue is too much and using the Project tool has a similar problem where it can become overwhelmingly noisy. Spreadsheet style lists are the cleanest way to see a lot quickly.

We're constantly amazed at how often we use Trello only for the purpose of drafting and organizing stories before we copy/paste them into Jira.

That, plus keyboard shortcuts for everything means developers will love it as well. This really feels slick.

Agree. Then again if you use JXL in your Jira you have a more agnostic spreadsheet view of your issues as well. Pretty neat. https://jxl.app

> 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 like the Assignee (as the table view in the new GitHub Issues does).

Yeah I think the design was made with an analog board in mind, where moving a task is easier than changing its state in place. But for a digital board tables definitely make more sense.

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.

> Extend issues with custom fields

Further support for my theory that every Trello eventually becomes a Jira.

Die a Trello or live long enough to become a Jira.

It’s funny because I can obviously see the value in the features they’re adding. It’s not ridiculous for people to want more control over task management in GitHub.

The thing that makes me sad about this is how customizable it is. Especially from GitHub, which has a pretty good track record of providing a good UX that mostly works well without such open ended customization. I used to look at GitHub as a great example of providing a good experience because the experience is opinionated.

All things come to an end, but I certainly wasn’t expecting “we have the most basic-but-integrated kanban board you could imagine” -> “we aped all the features of Trello and AirTable without scrutiny” without some intermediate step.

God this is Good. It also capture so much not just on Trello or Jira but Software in general.

The UI, down to the content and styling of menus, looks a lot like Linear. I'm chuffed to see the best parts being borrowed, but it looks like they've made sub-tasks/issues too simple, as they aren't first-class issues, but mere checkboxes with short descriptions.

https://linear.app

On the other hand the “tasks are as heavyweight as the bugs or backlog items that spawned them” (often with just one task ie 1:1) creates a ton of overhead in e.g Azure Devops. Especially as efforts get spread out while rollup barely works. It’s also unclear whether PRs should be linked to tasks or the parent issue.

I want more than a checkbox but less than an issue. A completion % and owner would be enough.

I often edit the description of an issue in linear just to breakdown the task using "markdown" checkboxes. In my mind: issues should correspond to a pull request and checkboxes to commits.

There is currently a move to disable issues (in opensource projects) and the driving factor behind this, is that other people can basically put stuff on your todo-list.

What would be better:

- make issues read-only for non-members

- track problems in discussions. often they're not really bugs and other people can directly help. If not, I'll convert the discussion to an issue when appropriate.

Benefit: bugs as discussions can be upvoted or downvoted so the community helps prioritizing.

I haven't used Discussions, but why doesn't Issues already do what you're asking for? You don't have to consider every open issue as your TODO list; use one or more "Triaged" labels for that. And voting on issues already exists.

I have not seen such a move in any of the projects I have looked at. Repo maintainers have either just allowed feature requests and ignore them but leave them there for either someone else to chip in on or just to show that it has already been requested. Or they will just close feature requests.

I am pretty deep into open source, and have not done this myself, or seen this anywhere? Examples?

Yeah, but the issues page is NOT a todo-list.

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.

It's extremely confusing the way the repos work in Azure DevOps as compared to GitHub, the only way you can see which one you are working on is through the little tab on the top. Since this also controls what PRs show up, about once every day or two I'll click on "pull requests" and be super confused as to why there's no PRs present until I realize "oh! I was browsing the other repo earlier that's why." Especially when issues and everything else are not connected to repos in any way, this is a weird UX decision. At least put the name of the repo next to the pull requests button like in GitHub, so I see where I am before I click.

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.

I'm more interested in GitHub's Issue Forms (as an evolution of Issue Templates): https://twitter.com/frenck/status/1355620350176976901

Does anyone know what the status of these is?

> Dive into work faster with issue forms and templates

Looks like its the same alpha/beta.

Thanks. I missed that list item, because it did not have a corresponding screenshot / screencast.

Shipped today. https://github.blog/changelog/2021-06-23-issues-forms-beta-f...

It's announced here as also being in beta for public repos: https://github.blog/changelog/2021-06-23-issues-forms-beta-f...

I cannot comprehend why GitHub chose to let people define the form elements in YAML (!) instead of simply allowing <input>, <select> and <textarea> in Markdown. One of the most beautiful aspects of Markdown is that it supports HTML. It's trivial to allow only a minimal set of attributes, like `required`.

I kind of hate this to be honest. I understand why maintainers use them, because "i am having issues running it, plz halp", but IMHO two paragraphs of a well-written report which contains all the information is better than:

== Describe the problem (huge header) ==

Description of the the problem.

== What did you expect? ==

That it worked

== What did you get? ==

A repeat of the problem statement.

== Which version did you use? ==

Repeat of what I wrote in the description where I mentioned I tried latest release 1.2.3 and the latest master.

etc.

I generally delete these templates, making sure the requested information is all in there of course. It almost always saves significant amount of space and makes things easier to read. I haven't had any complaints thus far.

I wonder how tense things are over at Atlassian right now. Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them.

Probably not that tense. A lot of enterprises with Very Big Licenses are hard-locked into Atlassian products with little to no chance of changing.

I suspect that Azure Dev Ops is more comparable to Jira and is their real MS competition.

So, yeh I partly agree.

However those orgs often have a Very Big License for GitHub Enterprise, and therefore with some enterprise porting tools it's not that high friction a switch (supplier managers will be all in favour; one less contract to manage!)

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 much, it sort of works.

I've never had a problem with the web UI. My only complaint is that it doesn't render Jupyter notebooks.

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).

Hard to be sure either way, but most of the sources I could find indicate this isn't true.

E.g. https://www.slintel.com/tech/source-code-management/github-v...

The problem is once you connect Jira to Confluence to Team Calendars to Crowd to BitBucket Server you're very deep into the lock-in.

Nobody has either the time or the will to switch because, while all the software kind of sucks, it doesn't suck enough to the point where someone is going to stop working on their product and/or service to jettison Atlassian from their org.

Not so much. If the company is large enough then some teams will have enough clout to break away. Our company is mostly Jira / Confluence / Bitbucket, but our team uses GitHub SCM/Issues/Actions now. Since we've led the charge other teams are starting to migrate as well.

I have a lot of awful things to say about GitHub Actions but it's probably the best fit for our team.

I was actually surprised how shallow and poorly functioning the integrations between JIRA / BitBucket / Bamboo and so on are. It all seems very basic compared to the default in OSS. In retrospect it's obvious that all of Atlassians products have been developed by separate teams / bought up and someone spent the bare minimum making each of them talk to each other.

You would think this -- then you look at their balance sheet and re-evaluate everything you think about software.

Most big corporations won't switch away from Jira and Atlassian in general anytime soon. If any changes would need to happen, it would take years.

I dont see this new feature as a threat to Jira. For some tech-focused companies, sure it might make sense that everyone is in Github as their overarching project management. For all the other "regular" businesses, Jira is a more 'party neutral' solution.

JIRA is going to be fine. You think their customers are the engineers who use the tool daily, but they are not. Their customers are the managers and bean-counters that track metrics and numbers at a macro. Their tool helps those roles mostly.

I hate JIRA but there is very little else serving these customers.

There's already a dozen great competitors for Jira.

Jira has a gigantic moat. Too many people - non devs mostly - are invested on it. While this new product is not negligible since it comes from a service people are likely already using, I'm sure Atlassian isn't scared in any special way.

Yes, but the moat has a lot to do with integrated products. This would be a step that way for Github.

first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use it to break all agile principles. third step is for your devs to take none of this seriously and put fake data into JIRA which your middle managers never catch onto. then your engineers who actually want to get shit done leave and you're left only with people who put fake shit into JIRA.

This is so close to reality it really hurts - like a good The Onion article... excellent satire.

Powerful tools are flexible enough to be used correctly by knowledgeable people and help people become knowledgeable. Badly designed tools are tools which don't help people become knowledgeable and don't prevent unknowledgeable people from harming themselves or others using them.

Atlassian tools, like JIRA, are almost always powerful and flexible -- capable of great good in the hands of knowledgeable people. However, they are not well designed tools, and so - the vast majority of JIRA installations and setups are just as broken as the orgs which install them and JIRA offers absolutely zero assistance or resistance to that brokenness.

Right, it turns into a political game instead of a powerful and useful tool. We have no control over how we use JIRA. It's all prescribed by someone and we don't even know who or how to reach out to them. Even the middle managers don't know how JIRA is being prescribed. They go one step worse and make Tableau dashboards from JIRA to track their own metrics that are so bad it's just... like The Office. We play the game though every day and get great feedback. This feedback is never from our customers (internal) though. Although they give us great feedback as part of the game too. Our actual delivery is very inefficient and slow though. The hierarchical structure of the org is such that feedback never makes it up the chain because that's highly discouraged. So they just keep wasting money.

Yes. Long feedback loops and perverse or misaligned incentives == PAIN. Tools like JIRA do absolutely nothing to discourage nonsense like that - and, in fact, provide features designed to support workflows which require them.

Yeah. it never makes sense to make any noise about it either because the people you can reach either don't understand the problem or don't have the power to fix it. It only makes the person making noise look bad.

sigh

Yeah.

The bad news is that I've never heard of a workplace that's managed to change that culture once it's set in. The good news is that there are plenty of places to work which don't have that nonsense - which you can work in, if you can find them; which, to be fair, is pretty difficult. That said, it's worth the effort.

That's one of the questions I ask potential employers - "Say I'd like to make a small change to the workflow, in order to meet an oversight requirement - for example, on a project I'm engineering - how would I go about doing so using your work tracking system? How many people would I need approval from to do so? Let's assume the effect is internal to my project and would require no other team to change how they work. Is that possible?"

The answer usually says a lot more about the prospective employer than any technical questions about their code-bases do - and those are generally easy to suss out with a quick inspection, and SCM log perusal, anyway.

This is super common, and it's one reason why I have always volunteered (even though it sucks) to be the Jira Person. I'm experienced with it and have a good handle on how not to make it a big giant workflow mess, and I can then make sure that, by not being shy about who's running it and managing it, that feedback goes somewhere actionable.

JIRA workflow is managed by another department. Our IT department is like 50k+ employees. I think there are 100k in IT and Ops.

Abandon all hope, ye who enter here.

Absolutely common. And I'll happily consult for companies in that boat but I would do a lot to avoid working for one.

Imho the power and customisability of Jira is great. The problem is just its UI and performance. There are solutions to that though. You can always JXL your Jira (https://jxl.app).

I think too many places try to treat their tickets system as a source of truth, rather than simply a work management system.

* A task with a title that can be understood in context (by the implementer/stakeholder) is sufficient.

* Pointing/effort estimate is even better. Ideally, everything should have points because it helps the team manage workflow and set expectations.

* A description is nice, but often completely unnecessary. In fact, I'd prefer no description to a stale description.

From there, individual teams/developers should choose whatever tools they prefer for actually implementing a feature.

Trying to use one tool as both a reporting-to-management system and a communication medium for the people actually doing the work, is a great way to make it fucking useless for both purposes. And yet, that's the norm with ticketing systems.

Don't forget trying to use it for "productivity metrics".

Also, even for the people doing the work overloading communications to include not just tracking/assigning work, but also describing the requirements or details

This is gold. I’m one of those engineers who left. But I didn’t leave before creating this tool for others who were staying behind. It automatically reassigns your JIRA tickets to someone else. Very handy right before stand ups and scrum of scrums where they look at who has the most open tickets.

The goodbye email where I linked to this was the highlight of my career.

https://github.com/jmathai/all-hands-on-deck

This is fantastic. Probably works best in a massive organisation; did that goodbye email burn any bridges?

> Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them.

I regularly meet with tech companies in the 2~10 person dev team range and easily 70%+ still use Jira. These co's have the choice of choosing Jira (i.e. it isn't being jammed down on them by a corporate overlord) yet there's still hate? I don't get it.

I'm beginning to think the Jira hate is simply an echo chamber about perceived overhead of project management by IC (mostly engineers), not Jira the actual product. Yes, Jira is complex, but it doesn't have to be. Most dev teams I know just need a tool to organize task intake and allocation. And most smaller ones use Jira because in most cases it'll come batteries included for a dev team.

PS - according to their financials, Atlassian is doing just fine: https://www.cnbc.com/quotes/TEAM?tab=financials

I work at a 2~20 person shop and other than the BigPicture Gantt chart plugin not scaling well, we're all more or less happy with Jira.

There was a lot more complaining during our self-hosted GitLab days but I can't recall a specific reason why.

This aligns with my experience talking to lots of small startups of this size. It amazes me that 2-man shops use Jira, but they do, because they know it from their previous jobs and don't want to bother finding/learning a new thing. We also run across Trello and Asana a lot.

I use Jira with 300+ users for both software and non software projects. I don't love it for either but I don't hate it enough to move. Any tool that offered 1:1 feature parity and a full migration, would only need something as simple as slightly cheaper or faster for me to move. IMO the administration is a pain even for simple things.

I've also been on Jira for at least 4 years now and the development is just sad... New UI stuff wasn't "better" just different. Pages are still slow if not slower. Reporting is abysmal; we use the API to pull pretty much all data into a database and report from that. The one tool our team's universally loved was canned– a browser extension that allowed you to screenshot and open ticket with things like browser info and URL already in the ticket. We even tried to modify the extension to put metadata from within our application (didn't work and product was sunset anyway).

My outlook is that developers will move towards something like Jetbrain's issue product or maybe even GitHub issues someday. Support teams will move towards a more dedicated support style system like zendesk or a custom solution around twilio. And for non dev projects, I hope better tools come up... Microsoft project seems to still be a leader in my industry, and also seems to be universally hated amongst my teams.

I am relatively new to this, completed one year at my job a while back. But I find Jira isn’t that bad. My teams have used Kanban boards to track stuff and I find it quite helpful. Sure, I forget to update my tickets every once in a while but it is a good tool IMO. So can you explain what you meant when you said the new UI isn’t better?

A few years back they started moving to a new UI that is visually a bit better but functionally I find slower to get to what i need. I also find the load times to be extremely frustrating, not sure if that’s related to new UI.

compare this experience to trello or github issues and you’ll see the other end of the spectrum. obviously jira does way more enterprise related features than those two.

Part of the issue with Jira is that it's possible to make it incredibly painful.

Stock Jira is not substantially worse than any other bug tracking system, other than being proprietary.

However, Jira is incredibly customizable, and if your organization adds a dozen mandatory custom fields, Jira can become horrific to use.

Workflow customization is one of Jira's selling points, and also one of its biggest dangers.

There's some value in a system that doesn't allow that level of workflow customization, and instead forces everything into a fairly simple and lightweight issue-tracking framework.

I personally am hopeful about this GitHub feature, but I do think there's a real danger of losing usability here.

We used Jira at a small tech company 10 years ago and I actually kind of liked it. At the time, it was the best out of a bunch of mediocre (affordable) options. It offered nice integration with our mercurial BitBucket repos and that code review tool they had (forgot the name). We just used a simple workflow, and it was overkill for what we used it for, but it worked fairly smoothly.

Haven't used it since though.

We tried to self-host initially, and our server with "only" 4G of memory (remember, this was 10 year ago, and was a respectable amount for a small office server) couldn't handle it; it was super-slow even with just a few people. lol? None of us were Java peeps and didn't really know how to tweak the JVM thing. We ended up just using the hosted option, which wasn't that expensive anyway (certainly cheaper than having a dev spend a day on this).

They're doing their best job slowly killing Trello.

For day-to-day, Jira is completely fine.

I get frustrated with it when I need to dive into basic admin tasks - like spinning up a new project or board. Their admin and setting panels are completely incomprehensible.

Also, Jira doesn't have a story for archiving tickets. Only a straight, permanent, hard delete with no recovery. I got reminded of this the hard way.

-----

We're currently switching to Clubhouse (though a completely unrelated thing was the forcing function). It comes with it's rough edges as well, but it's simple enough we can comprehend it within out headspace.

It's way too heavy, even for the day-to-day. A tool of that sort, for which I have to close tabs when not actively in use to save resources, even on powerful machines, or where clicking a link to a ticket might take more than very-low-hundreds of milliseconds to load, is bad.

GH issues? I click a link without thinking twice, and it's open fast. Almost every interaction is quick. I can leave a dozen tabs with GH issues open for weeks and not notice. Jira? Asana? "Ugh, a list of five issue links and I don't know which I need... fuuuuuck I don't want to open all these to find the right one, should take 10s total but will take a minute or so", and "why's my whole system feel weird? Damnit, I left Jira/Asana open again, didn't I?"

> It's way too heavy

It's basically the CPanel of ticket systems.

Same. My personal pet peeve is "workflows", aka, you moved something from To Do to In Progress, and now it's impossible to move back because its not part of one of the allowable paths for a ticket. It's just like... why. PMs spend all this time designing the workflows only to make more work for themselves when everyone needs them to manually move things.

Jira’s mobile interface is dreadful. Most features are missing and basic things like state survive a round trip through an sso flow are missing. They obviously lack any sort of customer obsession to let this persist.

I always got the sense that Jira is only universally hated by people who use it but have absolutely no say in whether they have to use it.

Having no say in having to use any piece of software is a straightforward way to make people hate it.

I don't think that will happen just because the real problem is how software like this is usually bought. They'll ask 20 departments for their (heavily conflicting) requirements and then chose the one that ticks the most boxes without paying any attention to usability, which automatically means jira. To compete with that you'd have to do the same thing as them, at which point your tool end up just as unusable. (also see: gitlab)

I bet they aren't too worried.

This seems like a product area where hitting all the features on a purchasing manager's feature list is more important than being good. Atlassian seems optimized for that.

Ex-Atlassian here. Last day was around a month ago.

Not tense at all. You'd be surprised at how many people actually like Jira, mainly because of how customizable it is. That in my opinion is it's biggest boon and its greatest curse. Every Jira instance is so different it's hard to compare between them. Stock isn't bad at all and works quite well. There are performance issues for sure, but I've yet to see a competitor that has the level of complexity Jira provides do so at a significantly faster speed.

For what it's worth, culture wise Atlassian was great because of how not tense things were. A lot of that is the Australian values in the company. It's very much work-to-live rather than the live-to-work of most Bay Area companies.

> You'd be surprised at how many people actually like Jira, mainly because of how customizable it is.

Are there any numbers of how many of the users like it, compared to how many users struggle with it? I can't imagine that a majority of Jira users likes it, as that's not my experience. I have met very few people (mainly project managers) so far, which believe that Jira (and other Atlassian products as well) are great products.

I have to say that I strongly believe that the hate for Jira doesn't come from Jira but from misconfigured workflows. I used to use a stock Jira in my last companies and never understood what people were complaining about. I had boards with the simplified workflow and the team had free reign.

I first started being annoyed by it when I joined a large corporation with a central department that would enforce specific workflows and processes. Now I can't move tasks into a sprint without assigning them to a person first, can't move task from status x to y and have a 100 custom fields in there. It's no fun anymore. At the same time the projects are owned by project management and it doesn't feel like home anymore. Where I initially opened up my Jira Board first thing every morning it now has become a chore.

At the same time I have to say that I kinda understand where those processes come from. I now work in an industry where accidentally using a wrong issue type or forgetting to assign issues to specific code changes can become an actual issue due to traceability requirements mandated by law.

They are so not bothered that they have started to "enterprise" Trello

Wow, there's a lot of Airtable in here. My team used GitHub Issues/Projects for a while, but ultimately moved to a custom Airtable solution for project management, release management, etc which gave us the tables, views, filters, groups, you name it. Seems like someone at GitHub got the notice about users wanting that more flexible UI/UX. Good on them!

This looks like a great step forward.

I always found it interesting that proposed enhancements are thrown into Issues. Maybe it's the word "issues" itself because I associate it with a negative connotation.

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.

I find it interesting that it sometimes shows my very own repositories (or repositories of one of my organizations) within the 'Explore repositories' section on the dashboard. As if I didn't know those repositories yet.

I sort by date to get around this and it helps a lot.

Side note: I also do this in HN Algolia search and it still annoys me that the default sort setting doesn’t work.

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

It's for people that want to find issues to work on in random repos, I suppose.

It does not only show issues, but also other content. What would you consider useful information?

As a PM who recently moved our eng team from Jira to GitHub (it was a good move btw), this is amazing news! It solves so many of the little problems that GitHub issue caused us, really looking forward to using it!

This doesn't seem to have the one feature I want most, which is the ability to track the status of projects and milestones that span multiple repositories. Anyone know if this is there and they didn't mention it, or is on the roadmap?

Yes, this is one of the main scenarios we are enabling in the Fall. Project tables and custom fields are already cross-repo enabled in the beta.

Oh sweet! This is great news, thank you.

Mariorod! As a company currently using GitHub issues, is there any way to jump onto the beta program quicker?

If anyone from Github is here, can you please allow attachments of unrecognized file types? You won't let users attach their binary .plist prefs files and this makes Github issues unusable for my project.

As you can guess there is a lot we do when it comes to attachments to keep the platform safe, which includes having an allow list of them. Now, I agree there is room for improvement and are looking into an attachment API that will address this.

Can't you already attach arbitrary files as part of a tagged release? You can also direct link to any file you want which works the same as if it was uploaded. I'm not sure the file whitelist is adding any security here.

I was hoping to see it mentioned that a collaborator can just be given issues permission (no code access), I’m assuming that’s still not possible?

I'll throw my random feature request in here since everyone else is:

Ability to write github comments as org mode instead of markdown

I wish it would just support "proper" Markdown where line breaks aren't treated as hard breaks. Makes it so much easier to copy stuff from Vim etc. I spend an inordinate amount of time J'ing lines together in Vim just to copy something to GitHub.

Nice.

Github has all the incentives and infrastructure in place to build all the layers on top of the repositories and existing social network. Ive seen a bunch of companies launch with competing project boards, ci systems, etc but its not clear how you carve out a space for yourself from within a set of reasonable defaults.

> Automatically add issues to a project,

That was the one thing I actually absolutely needed missing from current "Projects". Seems like such a simple basic thing, but the fact that I couldn't make it so a new issue created automatically showed up on a project board was a stopper for me.

Question: how does the Table view headings reconcile to the Board view?

On the Table view, there is a heading for: "Prototype", "Beta" and "Launch"

https://github.githubassets.com/images/modules/site/planning...

But when you look at the Board view, I don't see "Prototype", "Beta" or "Launch" denoted anywhere on the card.

https://github.githubassets.com/images/modules/site/planning...

By looks of it, they're milestones :)

But how do the milestones get surfaced on the Board view?

This is probably the slickest landing page I have seen in the last two years.

So for a non-developer that wishes to collaborate, they now need a GitHub license? That's a deal-breaker right there for any org that is composed of more than developers.

At my org we just have one user with reporter permissions on gitlab which is shared by a bunch of people who just write their name at the end of tickets or comments. For more involved people who need to be assigned to things or pinged, they pay the full license.

Airtable is the most amazing thing that has happened to UI in years and it's really nice to see their ideas crawling on to other contexts like GitHub here.

Is there any info on how this would help with estimation and planning of a large number of tasks. E.g. "what can we get done this quarter?"

I have an eye on https://www.openproject.org/ because it seems to have these sort of features. I currently use Excel for this.

Really looking forward to the boards & ability to split check boxes out into new tasks. Being able to decompose business issues into workable technical items has always been a challenge for us. The impedance of needing to create a new issue and copy stuff over from the big one would encourage us to not always do this.

Oh me and everyone I know have been waiting for this.

Why use any other Issue tracker if Github can do this itself? Countless integrations would be replaced by this. I wonder what would happen to all those dashboard / issue tracker / project tracking apps now.

I've mixed feelings.

On one side, I like seeing something different to the crap that is Jira. Every single large company out there seems to use it and it's terrible.

OTOH, not sure if I'm happy that the only new competition is a Microsoft product.

I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub.

Am I wrong about this?

Yes. Issues are a Github feature, not a Git feature.

I mean, isn't that the case for practically any issue tracking system? Which ones store their issue (and comments, etc) within the repo?

Fossil!

https://www.fossil-scm.org/

Why are you using Github if not for their social features?

Github's social/discovery features are too strong - it makes it difficult to justify keeping OS projects on GitLab even if the feature set is better for maintainers

I can't tell if you're joking, but if not I use it because it's a reliable, free git server.

Not sure why you’d think that. Maybe this is common in your circle but I don’t know anyone who uses github just to host a remote repo.

You literally have to pay to have a private repo. It isn't just a common use, it is feature you have to pay for.

The GDPR mandates that all web services allow you to export your data which github supports. Alternatives like gitlab allow you to import all of that "proprietary" data direct from github so its not a very strong lock in.

I'd like to be able to run reporting out of this so I can gather velocity metrics (for my boss) at the developer/project/milestone/arbitrary label level. It doesn't look like there are too options for this yet.

rip zenhub

Reminds me of https://height.app/. I highly recommend giving it a go.

I am NOT envious of Zenhub right now!

There's still nothing available today that's remotely as useful as Bugzilla, imho.

Are you people still with status "on waiting". I'm looking forward to this.

What ever happened to Fogbugz?

Still around, https://fogbugz.com/ but owned by somebody other than Fog Creek.

Fogbugz is Fog Creek :-)

The lone and level sands stretch far away

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.

But will they link Pull Requests to issues anytime soon?

I am surprised no one has mentioned Asana.

When will gitlab get this?

GitLab provides issues, boards, epics, time tracking, road maps, and more as part of the Plan stage: https://about.gitlab.com/stages-devops-lifecycle/plan/

Yes but with as nice of a UX.

Proprietary platform, quite an easy pass.

I can't tell if they've handled it here, but one of the things I'd love to see is a "friendly" view into issues for non-coders. In my experience, when a non-coder sees something that "looks like code" they become confused and frightened and generally avoid the interface.

Omg, they did a copy of Asana. And not a copy of the good part, but a copy of the useless unergonomic eye candy parts ...

And I hate so much Asana... It is so inefficient and frustrating to use.

So, please, fire the designer that proposed this change before it can become mainstream.

I don't understand the hype about the "board" thing. I guess that people think that they look cool and doing agile by using a board.

But compare that to a normal table that you can reorder by columns based on your wishes...

What view and UI you think would be the most efficient for this?

Reply on news.ycombinator.com