Day 50 trillion of begging Github for a functional notification system so I can stop receiving infinite numbers of emails from all the bots and similar things commenting on PRs.
Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.
Codeowners are added as a reviewer to every PR that touches a file under their (team) ownership. In a large codebase it can easily happen that a large % of PRs changes something you're a codeowner for.
Well I do (basically 99% of github emails are auto-purged from my email inbox), but the problem is that the github platform itself on the notifications page is unusable. It'd be nice if I could use it!
A GitHub feature I think would be really handy is suggesting duplicate issues when writing up a new issues. Many projects ask that you search for already reported tickets, but GitHub's current search isn't great if you aren't sure what you are looking for.
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
We made a similar thing too for our community discord where you can add an Emoji on a message and it will look for similar issues with a simple RAG. That saves us so much time when a user asks if a feature is planned or not.
We also ask them to go upvote the issue or create one in the response.
Not open source right now but if people are interested I could clean up the code.
If only Microsoft was interested in finding actual useful use-cases for their machine learning tech instead of constantly selling everyone on their chat bot...
If we're talking issues (i.e. reports from external parties, like OSS users, and not internally defined tasks), then care is needed to avoid it working out like the Stack Overflow experience. What is it, you ask?
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
I refuse to work with projects with a stale bot. As if ignoring an issue will just magically resolve it. I also refuse to use products with a stale bot once I discover it is used; they are usually bug ridden due to uncovered issues being ignored.
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Cynical answer: because having users writeup duplicate issues and then having maintainers close them is more engagement than warding off unnecessary toil. Gotta keep those metrics going up and to the right.
> This means there are no new UI patterns to slow you down,
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
Longer paths, especially ones like these that require keyboard input, are especially painful from an accessibility perspective, where for most cases such typed fields make things take exponentially longer than if it can be achieved by just clicks/tabs/arrows.
I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great.
It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.
But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.
The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
I like GitHub precisely because it didn't try to capture the entire market of issue trackers and code search too aggressively.
If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.
Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.
Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.
Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.
> There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues).
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.
I feel like ticketing is something that has been pasted on for corporate reasons.
Keeping track of the work to be done doesn't require a ticketing system,
anyone remember using Story Cards? A whiteboard?
Don’t forget code review. I created CodeApprove, but there are so many other good alternatives that could have been GitHub features (Graphite, CodePeer, Reviewable, etc).
FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right, mainly because it has to work somehow with the existing issues feature set. People building this feature from scratch (e.g. Linear) have it trivial to solve, because they didn't have any backwards compatibility issue to worry about. This is, of course, absolutely Github's fault for not designing it to accomodate such a thing easily in the first place, but the people who built this feature are probably not the same people who made that original decision.
They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it.
But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
> FWIW, this specific feature - what they are now calling sub-issues - is actually better described as a framework for modeling proper parent-child relationships in their system, which is something quite hard to get right
That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.
Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?
Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.
Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.
Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).
> I started programming right when they got started.
Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.
GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.
Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.
I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.
Great, a few more decades and it might become a usable bugtracker.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
I believe Apple silicon has Jira coprocessor. It really became usable on M1 and beyond. Even the horrid UX got somehow better in the last few years (like not having 3+ different text inputs, each with different formatting behavior). My guess is since the hardware caught up with them they can now finally use it and iterate.
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
Yeah I have no confidences in GH to become viable for issue management for large commercial projects.
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
I'm curious if there are folks here who work at for-profit orgs who use GitHub projects as their sole issue tracker for the entire org. How do you do it and what are the common pain points? Do you couple it with other issue trackers/project management tools like Jira? If so—why?
I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.
We did at my previous employer (https://www.ourbranch.com/) in our data org. I can't totally remember, I'm pretty sure the engineering org did, too. It definitely is lacking in some of the advanced features you get with a Jira, but it was fine. I was surprised by how powerful GitHub Projects is. We also built out extra reporting for it in our data warehouse, using Fivetran for ELT.
1. Does the data org work in isolation from other orgs? I'm guessing not.
2. Does the data org consist of non-engineers? If yes, are they also onboarded into GitHub with their own GH accounts?
3. If (1) is no, what tool is used to track cross-org work? Does the company also use Jira or some other tool and is GH projects integrated with them or something? I'm really curious about this workflow if it is relevant to how you folks work.
We ditched Jira to go all-in on GH. It's nice having the project management in the same place as where the actual work happens. It's not perfect, but it's better than GH + Jira.
Probably the benefit I'm most happy with are that people are writing more, and in greater detail. I don't know why that is. For some reason, the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Interesting. Are you an all-dev org or did you also onboard non-devs into GH Projects?
> the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Huh, that's interesting to hear. I didn't personally find it harder to add detailed descriptions in Jira back when I used it couple of years back. Wonder if there's anything specific about the experience you can describe that makes you feel GH projects is more friendly for writing.
We were interested in Issues and Projects, but the number of people at an organization who need access to those but not to code or CI is pretty large. GitHub does not have a different license option for BA/CX/PM types. We ended up going with Jira for tasking, which was substantially cheaper.
I was sad about this because issues/projects had all the stuff I personally cared about, and there was no need to work to set up integrations. I think there was some anxiety by the PMO that it wasn't mature enough for what they wanted, but I don't remember any specifics. Probably something about reporting.
That's how I feel as feel. It's costly given the things non-devs types won't need and it's not fleshed out enough to attract those types of folks to make the switch. GitHub is probably missing the boat tbh. Even the marketing page (https://github.com/features/issues) is targeted at developers.
We do at Grafana - it's mostly all public so you can go look at the mess of trying to run jira boards for however many teams out of one repo https://github.com/orgs/grafana/projects. It's a mixed bag, but Github's been building out Issues and Projects a lot in the last few years that's really improved things.
We do. We're an agency so there's probably 60 odd repos on GitHub each with a project attached, a lot of non-tech people (even clients) using the issues and boards. Nobody has complained, though every now and then I've looked around for something else, but for me the number one priority is that the code and issues are in perfect sync with each other - much harder with a 3rd party tracker.
Absolutely. They definitely can't expect to sell this to teams/orgs with non-devs without introducing separate pricing for folks who just want to read/write to projects but maybe read-only for some aspects of a repo.
We tried (dev-centric org) but the non-technical users weren’t able to use it well / didn’t like it - so now we don’t have issue tracking at all for non technical stuff -.-
Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago.
Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).
Readit News
Also being designated a codeowner in a large repo, the number of notifications I get daily from the number of PRs is fucking absurd, with no way of turning them off. Drives me up the wall daily. If a colleague doesn't straight up send me a PR in a DM, I'll basically never see it because I've given up on the notification screen a looooong time ago.
Deleted Comment
For fun, I had put together a GitHub bot for this purpose a while ago. It indexes all existing issues in a repo, creates embeddings and stores them in a vector DB. When a new issue is created, the bot comments with the 3 most similar, existing issues, from vector similarity.
In theory, that empowers users to close their own issues without maintainer intervention, provided an existing & solved issue covers their use case. In practice, the project never made it past PoC.
The mechanism works okay, but I've found available (cheap) embedding models to not be powerful enough. For GitHub, technology-wise, it should be easy to implement though.
https://github.com/alexpovel/issuedigger
Not open source right now but if people are interested I could clean up the code.
[Closed; Locked: not constructive; Duplicate of: #1701, #74656]
Users will fight such things for a simple reason: every larger OSS project has tons of open[0] issues that look like duplicates, and perhaps even are duplicates, but no one can tell because they're all ~forever old and unresolved, so new people keep adding them again to bring attention to them.
Perhaps Github should start sorting issues by "Last updated" instead of the issue number - then some of the duplicate reports would just turn into "+1"s and "bump!"s on the existing issues.
--
[0] - Or closed by stale bot, which is effectively still open, but with an insult on top.
Ive often wondered why GitHub hasn’t introduced this feature because it feels like a really obvious thing to introduce and something that would add an immense amount of value to a lot of projects.
Deleted Comment
So I wrote a simple app for fun to navigate and search GitHub issues like emails and even reply
Screen recoding https://x.com/justruky/status/1878507719520387347
But you’re completely right, GH search is truly bad
Deleted Comment
Sure there are, it's a common UI design mistake - you can't do advanced without breaking the basics: previously you could filter your issues with a drop-down filter in 2 clicks. The PR tab still has this (inconsistency) while the new issue requires a worse and longer path that uses a typed field, bringing up you phone keyboard as a downside
It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.
But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.
The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.
If GitHub sub-issues had existed even in an inferior form back in 2019, developer-targeted trackers like Linear and Shortcut would have had a hard time existing, and all of their ideas (some of which have advised the UX of today's GitHub sub-issues release!) would have been lost to time.
Now, perhaps this was not value-maximizing to Microsoft, or value-maximizing to companies who now need an extra license for Linear - but I would argue that for actual developer experience, GitHub fostering a spirit of innovation through its own stagnation has created a vibrant ecosystem better than anything any company could do themselves.
Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.
I don't agree, and I cannot understand what train of thought would lead to conclude that each individual feature that's a crucial part of any developer's workflow should be broken down to external companies without any good reason at all.
Any developer's workflow consists of a) ticketing, b) revision control, c) auditing code and change history, d) CICD. Obviously a) b) and c) are tightly coupled and you cannot have one without the other, whereas d) invariably leads to a) b) and c) in any incident response scenario. There is no argument that justifies any alternative to a unified developer experience.
They've been working on some version of this feature for several years now in various iterations. I believe this is either their third or fourth attempt to get it right - I was trialing a beta of some previous iteration of it a few years ago and it was incomplete/not fully well thought out which must be why they dropped it. I'd trust the feature here at least to be decent now, because of how many attempts they've had at it.
But yeah if I was a company like Zenhub I would be probably a bit worried at this announcement since it is almost inevitable that this specific feature is going to be enough for people to no longer need third party management of issues. I know in a previous company I worked for that specific feature (proper parent-child relationships) was the reason they used Zenhub, and same for my current company using Linear.
That's a wrong framework to use. Parent/child relationship is a special case of dependencies between tasks, which can be more generally modeled as start/finish relationships, i.e. one of: Start-to-Start, Start-to-Finish, Finish-to-Start and Finish-to-Finish; parent-child relationship is Finish-to-Finish here. This distinction starts to matter if you want to plan out more work items than you can quickly eyeball on a Kanban board, and it's all well-trodden ground with nearly century worth of prior art, to which our entire industry is entirely oblivious.
Useful search terms: PERT, Gantt charts, critical path, PMBOK.
Popular software occasionally spotted in use in our industry (usually by PMs, in secret) that supports it: MS Project, maybe Jira, ... is there anything else?
Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).
Then let me tell you about SourceForge. SourceForge, around the time that GitHub started, had a lot of these features (or at least, the ones that were standard practice at the time). It was the de facto home of open source software development at the time, but it was also a megalith that tried to do everything.
GitHub was a breath of fresh air precisely because it had just the right balance of minimalism and features. There were plenty of truly minimalist hosts out there, so we didn't need any more of those. But we also had lots of bloated and slow code hosts. And it deserves to be stressed that the bloated ones were just as unusable as the minimalist ones, even while being (again, for the time) as feature-complete as they come.
Bloated products can't pivot. New features often don't integrate well with existing ones, and they take a long time to develop. We're seeing this with GitHub too, as feature velocity has dropped. But the difference is that GitHub's feature set, particularly their core initial feature set, was exceptionally well designed. They've lost a bit of this edge over time, but overall I think they've done a well enough job of balancing the thoughtfulness of their build-out with doing things at a reasonable speed.
I just want to emphasize this point because I think it gets lost, especially if you're not familiar with what the competition of the time looked like. GitHub absolutely would not have made it to where it is today if they had rushed to add features. For a comparison of what it looks like to build features first and put design on the back burner, see GitLab. There's a reason why I still find their product difficult to navigate despite it being one of the main tools I use in my day-to-day work. And I fear that if anything, GitHub is succumbing to the lure of feature count and becoming its own bloated monolith over time, even with their slow pace.
What's next on the list? Maybe priority/severity or status/resolution?
I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.
Based on my experience that doesn't exist.
Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah.
A colleague joked that we need a "waiting for Jira" Jira task.
If it's used for tracking issues, it's great.
If a team just uses it for keeping track of its ongoing work, it ok.
If the team also uses it to plan work, it works less well.
If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way?
If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
https://thedailywtf.com/images/200802/manualJira.jpg
Dead Comment
That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags.
How do you envision this differing?
I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
This is also what is happening with GH issues.
Compared to SN, Jira is a breath of fresh air.
I still feel GH Projects is solely aimed at OSS or dev-centric or dev-only orgs and doesn't cater to teams with non-devs, which is how I think most orgs function. I'm not sure if it'll ever try to be something more than that but I really wish it did.
1. Does the data org work in isolation from other orgs? I'm guessing not.
2. Does the data org consist of non-engineers? If yes, are they also onboarded into GitHub with their own GH accounts?
3. If (1) is no, what tool is used to track cross-org work? Does the company also use Jira or some other tool and is GH projects integrated with them or something? I'm really curious about this workflow if it is relevant to how you folks work.
Probably the benefit I'm most happy with are that people are writing more, and in greater detail. I don't know why that is. For some reason, the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
> the GH experience just encourages writing, whereas the Jira experience seems hostile to it.
Huh, that's interesting to hear. I didn't personally find it harder to add detailed descriptions in Jira back when I used it couple of years back. Wonder if there's anything specific about the experience you can describe that makes you feel GH projects is more friendly for writing.
I was sad about this because issues/projects had all the stuff I personally cared about, and there was no need to work to set up integrations. I think there was some anxiety by the PMO that it wasn't mature enough for what they wanted, but I don't remember any specifics. Probably something about reporting.
You'd miss the infinite complexity of Jira workflow configuration, but that might be a good thing.
Yes, I'm an advisor for such a company. They are using Github Projects/Issues for all their internal development.
Their customer support uses a different ticketing system, though. Mostly because they need to interact with external users.