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.
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.
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.)
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.
"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.
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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/
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
Also, even for the people doing the work overloading communications to include not just tracking/assigning work, but also describing the requirements or details
> 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.
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.
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.
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).
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.
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.
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.
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.
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.
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!)
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 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).
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.
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?"
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 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 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.
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.
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!
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.
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.
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?
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 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.
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.
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.
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.
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 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.
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
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.
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.
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.
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.