[HN Gopher] New GitHub Issues Beta
___________________________________________________________________
New GitHub Issues Beta
Author : splitbrain
Score : 361 points
Date : 2021-06-23 16:50 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fancy_pantser wrote:
| 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
| alkonaut wrote:
| 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.
| nthngtshr wrote:
| rip zenhub
| quicklime wrote:
| > 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 forms like
| the Assignee.
| djrockstar1 wrote:
| 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.
| eyelidlessness wrote:
| > Extend issues with custom fields
|
| Further support for my theory that every Trello eventually
| becomes a Jira.
| munificent wrote:
| Die a Trello or live long enough to become a Jira.
| jrochkind1 wrote:
| > 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.
| thinkingkong wrote:
| 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.
| smusamashah wrote:
| 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.
| momothereal wrote:
| It's for people that want to find issues to work on in random
| repos, I suppose.
| derpixeldan wrote:
| It does not only show issues, but also other content. What
| would you consider useful information?
| linkdd wrote:
| 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.
| eyelidlessness wrote:
| 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.
| TimWolla wrote:
| 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.
| WillAbides wrote:
| related blog post: https://github.blog/2021-06-23-introducing-
| new-github-issues...
| javier123454321 wrote:
| But will they link Pull Requests to issues anytime soon?
| TimWolla wrote:
| 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?
| cridenour wrote:
| > Dive into work faster with issue forms and templates
|
| Looks like its the same alpha/beta.
| TimWolla wrote:
| Thanks. I missed that list item, because it did not have a
| corresponding screenshot / screencast.
| martinwoodward wrote:
| Shipped today. https://github.blog/changelog/2021-06-23-issues-
| forms-beta-f...
| tomwas54 wrote:
| It's announced here as also being in beta for public repos:
| https://github.blog/changelog/2021-06-23-issues-forms-beta-f...
| felixfbecker wrote:
| 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`.
| aparsons wrote:
| I am NOT envious of Zenhub right now!
| dreamcompiler wrote:
| 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?
| Kaze404 wrote:
| Yes. Issues are a Github feature, not a Git feature.
| mynameisvlad wrote:
| I mean, isn't that the case for practically any issue tracking
| system? Which ones store their issue (and comments, etc) within
| the repo?
| Kaze404 wrote:
| Fossil!
|
| https://www.fossil-scm.org/
| baby wrote:
| Why are you using Github if not for their social features?
| dreamcompiler wrote:
| I can't tell if you're joking, but if not I use it because
| it's a reliable, free git server.
| Lorin wrote:
| 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
| plasma wrote:
| 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?
| munchkinship wrote:
| 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.
| dboreham wrote:
| There's still nothing available today that's remotely as useful
| as Bugzilla, imho.
| rbarnes01 wrote:
| 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.
| fairpoints777 wrote:
| Timing in this is perfect for us. Having yet another tool and
| custom apis or zapiers adds a lot of friction, we were going for
| I think zenhub but this will suffice
| bob1029 wrote:
| 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.
| gnachman wrote:
| 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.
| mariorod wrote:
| 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.
| thoughtpeddler wrote:
| 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!
| FionnMc wrote:
| 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!
| greatgib wrote:
| 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...
| HatchedLake721 wrote:
| What view and UI you think would be the most efficient for
| this?
| dorian-graph wrote:
| Reminds me of https://height.app/. I highly recommend giving it a
| go.
| [deleted]
| hi_mom wrote:
| 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.
| foepys wrote:
| 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.
| easton wrote:
| 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.
| baby wrote:
| This is probably the slickest landing page I have seen in the
| last two years.
| hairofadog wrote:
| 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.
| dancemethis wrote:
| Proprietary platform, quite an easy pass.
| telaandrews wrote:
| 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.
| nathanaldensr wrote:
| 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.
| jmcphers wrote:
| 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/
| dragosmocrii wrote:
| 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.
| nathanaldensr wrote:
| I think Microsoft does this with their .NET ecosystem of
| repositories, issues, and projects.
| telaandrews wrote:
| 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?
| tomjakubowski wrote:
| 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-...
| duped wrote:
| 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.
| SahAssar wrote:
| The monorepo question is not a question with a one-fits-
| all answer.
| adrianpike wrote:
| 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.
| nemothekid wrote:
| 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.
| zomgwat wrote:
| 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.
| telaandrews wrote:
| 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).
| tshaddox wrote:
| 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.
| munk-a wrote:
| 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.
| DaiPlusPlus wrote:
| GitHub issues should not be used by non-technical contributors
| though (imo)
| seph-reed wrote:
| 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.
| johnchristopher wrote:
| I agree. But many projects redirect users to Github for
| issues and SO for documentation :/.
| munk-a wrote:
| 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.
| petepete wrote:
| 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.
| cyral wrote:
| 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.
| SahAssar wrote:
| 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.
| tomjakubowski wrote:
| 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!
| mchusma wrote:
| 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.
| bob1029 wrote:
| 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.
| martinwoodward wrote:
| 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.
| buro9 wrote:
| 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.
| munk-a wrote:
| 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.
| martinwoodward wrote:
| It is indeed now possible. Give it a try and let us know
| what you think.
| mook wrote:
| 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!
| dbingham wrote:
| 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.
| nixpulvis wrote:
| Just make a repository named "jira" or "support tickets" and
| move forward, no?
| adambatkin wrote:
| 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.
| eisa01 wrote:
| 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
| AdamN wrote:
| Where did you end up?
| telaandrews wrote:
| 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.
| rawfan wrote:
| 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.
| Arnavion wrote:
| 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.
| tyingq wrote:
| 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.
| bovermyer wrote:
| 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.
| addicted wrote:
| I suspect that Azure Dev Ops is more comparable to Jira and
| is their real MS competition.
| ErrantX wrote:
| 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!)
| robinhood wrote:
| They mostly don't. Once you have Jira, you have Confluence,
| then Bitbucket. That many less contracts to manage.
| foobarbazetc wrote:
| 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.
| swebs wrote:
| I've never had a problem with the web UI. My only
| complaint is that it doesn't render Jupyter notebooks.
| foobarbazetc wrote:
| 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.
| formerly_proven wrote:
| 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.
| vinceguidry wrote:
| 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.
| sergiotapia wrote:
| 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.
| ATsch wrote:
| 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)
| jjcm wrote:
| 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.
| foobarbazetc wrote:
| You would think this -- then you look at their balance sheet
| and re-evaluate everything you think about software.
| SkyPuncher wrote:
| 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.
| handrous wrote:
| 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?"
| ohyeshedid wrote:
| > It's way too heavy
|
| It's basically the CPanel of ticket systems.
| waylandsmithers wrote:
| 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.
| whatever_dude wrote:
| 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.
| tyingq wrote:
| Yes, but the moat has a lot to do with integrated products.
| This would be a step that way for Github.
| robinhood wrote:
| 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.
| [deleted]
| ec109685 wrote:
| 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.
| denimnerd42 wrote:
| 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.
| SkyPuncher wrote:
| 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.
| handrous wrote:
| 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.
| phkahler wrote:
| Don't forget trying to use it for "productivity metrics".
| jacobr1 wrote:
| Also, even for the people doing the work overloading
| communications to include not just tracking/assigning
| work, but also describing the requirements or details
| jmathai wrote:
| 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
| [deleted]
| justinjlynn wrote:
| 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.
| denimnerd42 wrote:
| 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.
| eropple wrote:
| 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.
| denimnerd42 wrote:
| JIRA workflow is managed by another department. Our IT
| department is like 50k+ employees. I think there are 100k
| in IT and Ops.
| akiselev wrote:
| Abandon all hope, ye who enter here.
| eropple wrote:
| Absolutely common. And I'll happily consult for companies
| in that boat but I would do a lot to avoid working for
| one.
| justinjlynn wrote:
| 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.
| denimnerd42 wrote:
| 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.
| justinjlynn wrote:
| _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.
| [deleted]
| mbesto wrote:
| > 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
| thebooktocome wrote:
| 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.
| t3e wrote:
| 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.
| JoshTriplett wrote:
| 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.
| rileytg wrote:
| 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.
| anshumankmr wrote:
| 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?
| rileytg wrote:
| 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.
| JamesSwift wrote:
| 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.
| tshaddox wrote:
| 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.
| louisvgchi wrote:
| Having no say in having to use any piece of software is a
| straightforward way to make people hate it.
| whalesalad wrote:
| They're doing their best job slowly killing Trello.
| cuddlybacon wrote:
| 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.
| jmcphers wrote:
| 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?
| mariorod wrote:
| 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.
| FionnMc wrote:
| Mariorod! As a company currently using GitHub issues, is
| there any way to jump onto the beta program quicker?
| jmcphers wrote:
| Oh sweet! This is great news, thank you.
| Groxx wrote:
| "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.
| alooPotato wrote:
| 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.
| SkyPuncher wrote:
| 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.
| agentdrtran wrote:
| Their spreadsheet view reminds of Airtable a bit, or the
| notion-like tools that are very popular right now.
| adt2bt wrote:
| That, plus keyboard shortcuts for everything means developers
| will love it as well. This really feels slick.
| [deleted]
| dempsey wrote:
| 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.
| ed_blackburn wrote:
| What ever happened to Fogbugz?
| c17r wrote:
| Still around, https://fogbugz.com/ but owned by somebody other
| than Fog Creek.
| alberth wrote:
| 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...
| TGRHavoc wrote:
| By looks of it, they're milestones :)
| alberth wrote:
| But how do the milestones get surfaced on the Board view?
| sandGorgon wrote:
| 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.
| Lorin wrote:
| Scoped labels are the primary thing keeping me on GitLab
| swozey wrote:
| 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...
| bostonsre wrote:
| 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?
| coffeemug wrote:
| 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.
| isbadawi wrote:
| This seems to be covered by the new ability to extend issues
| with custom fields.
| sandGorgon wrote:
| 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.
| [deleted]
| KaoruAoiShiho wrote:
| When will gitlab get this?
| john_cogs wrote:
| 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/
| KaoruAoiShiho wrote:
| Yes but with as nice of a UX.
___________________________________________________________________
(page generated 2021-06-23 23:00 UTC)