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/
New GitHub Issues Beta
41–50 of 223 posts
Re: New GitHub Issues Beta
#42This 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.
Re: New GitHub Issues Beta
#43I 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.
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.
Re: New GitHub Issues Beta
#44It 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.
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?
Re: New GitHub Issues Beta
#45It 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.
Re: New GitHub Issues Beta
#46So 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.
Re: New GitHub Issues Beta
#47Earlier quoted context omitted.
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?
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.
Re: New GitHub Issues Beta
#48It 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.
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.
Re: New GitHub Issues Beta
#49Earlier quoted context omitted.
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.
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.
Re: New GitHub Issues Beta
#50If 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.