[HN Gopher] GitHub Issues-only project management
___________________________________________________________________
GitHub Issues-only project management
Author : JonathanBuchh
Score : 153 points
Date : 2021-08-21 16:56 UTC (6 hours ago)
(HTM) web link (blog.placemark.io)
(TXT) w3m dump (blog.placemark.io)
| mgbmtl wrote:
| If anyone from Gitlab is reading: our OSS community would love to
| use Gitlab for everything, but we don't seem to be able to:
|
| - disable the "packages and registry" menu item for the project
| (despite disabling it in the permissions) - odd help texts, such
| as "enable LFS to upload a design" displayed to non-admins -
| can't hide the service desk menu item, despite permissions.
|
| I understand it's not an easy compromise to balance discovery and
| user-friendlyness, but then we have people in our community who
| repeat "gitlab is only for devs" because of this.
|
| Example: https://lab.civicrm.org/support
| Stratoscope wrote:
| I am embarrassed to admit that my most popular GitHub repo is an
| issues-only tracker for something I didn't even create: a popular
| ham and commercial handheld radio, the AnyTone
| AT-D868UV/AT-D878UV.
|
| After I bought my radio, I found a few firmware issues and looked
| for a way to communicate them to the manufacturer. No luck on
| that. There was an active Facebook group, but it was a weird
| place run by a radio dealer who would ban you for discussing
| anything he thought might interfere with his business.
|
| So I made a repo and started adding issues for the things I'd
| noticed. People found it and it took on a life of its own. The
| most popular issue is a lengthy collaboration among several hams
| who worked out a way to load the D878UV firmware onto later
| versions of the D868UV (the hardware is the same).
|
| This was one of the topics that would get you banned on that
| Facebook group, as the group owner would rather sell you a new
| radio. The funny part is that the upgrade involves buying a
| special programming board and considerable time and effort, plus
| the risk of ruining your radio. So it was really just a labor of
| love for a few hams who had a blast working out how to do the
| upgrade.
|
| Hams may not build our own radios as much as we used to, but we
| can still hack the firmware!
|
| https://github.com/geary/AnyTone-D868UV
| jeffnappi wrote:
| GitHub issues + ZenHub is a great combo.
| derefr wrote:
| I tried ZenHub back before GitHub had Projects, but I thought
| that Projects had feature parity with ZenHub. What's the
| advantage of using ZenHub at this point?
| rgbrgb wrote:
| We used it as a layer for rough point / estimation tracking.
| Not sure that's needed though TBH, in another iteration we
| had just put estimates as labels and that worked well. I
| really don't care for burn-down charts and the like, but it's
| useful to see easily sum up how many points you have in a
| sprint. I always wondered why github didn't add this one
| feature... but at the same time I think it's such a better
| tool than Jira because it's so much simpler.
| qaq wrote:
| There was great video on how github does it How GitHub uses
| GitHub to plan and track work
| https://www.youtube.com/watch?v=UTDAlZFhPyM
| majkinetor wrote:
| You always need repository IMO, even just as DMS system to backup
| issues. You always need some files along with issues and copy
| pasting them directly into issue is not good idea (+ low number
| of formats supported).
| axegon_ wrote:
| Not github but gitlab EE - we used that at my old job for pretty
| much everything(and because none of the people on my team could
| stand the jira-confluence duo).
| rubyist5eva wrote:
| My last company had a change of leadership and dumped Jira for
| Github Issues, since we were already paying for Github and
| everybody hated Jira anyway. We made extensive use of Github
| Actions with it as well.
|
| Worked great, would recommend.
| jrockway wrote:
| Not super convinced.
|
| First off, I am not sure why people like Kanban boards so much.
| It seems like the most inefficient way to display issues possible
| -- you can't see the details, the title gets cut off into lines
| of 4 letters each, and you still have horizontal and vertical
| scroll bars. The idea of Kanban was that if you didn't have space
| for a card, you wouldn't take on the task. To some extent, this
| can work for software; you can say "there are a maximum of 3
| changes per release", and so if there are 3 cards in the "to be
| released" column you know you have to do one before anything else
| can proceed. But nobody has that rule. Meanwhile, does it apply
| to all the columns? Like, you can't report a bug in the software
| if the backlog column is full? It makes no sense to me, and I
| think it's a huge anti-pattern.
|
| I much prefer Linear's cycle view ("sprint view" for those of you
| that think sportsball metaphors play well with software
| engineers), where you can group issues and they show up as the
| category and then a list of issues that take up the entire
| horizontal width of the window -- so you can see what's in
| progress, what's to do, what's done, what's released, at a
| glance. Or during cycle planning, you can group by assignee and
| see that someone who is on vacation for one week and oncall for
| the other has 8 XL tasks assigned to them, and not commit to that
| impossible plan.
|
| I'm not a fan of Github Issues. I find everything I want to do to
| be very high overhead. If I want to open three issues, I have to
| navigate to the issues page, click "create new issue", type a
| title, type a description, click "tags", type the name of the
| first tag, click it, delete the stuff I already typed, type the
| name of the next tag, click it, etc. Then you submit, and you see
| the issue that you just submitted. To file the next issue, you
| hit back twice, click "new issue", and repeat. It is incredibly
| tedious, and people flat-out don't file issues for stuff they're
| working on. (Projects and Milestones are similarly high overhead.
| They're infinitely configurable, so useless out of the box, and
| therefore require a bunch of setup you have to do for every
| project. If you treat Projects as their version of Epics, then
| you probably need a Terraform script of something just to get the
| right columns on the board, which as I mentioned I don't even
| like.) Github's workaround for all of this is some automation to
| make PRs close issues, and that's about it.
|
| Github is also awful with notifications. If someone comments on
| an issue assigned to me, nothing happens. If someone @mentions me
| in a Github issue, it notifies my phone. If someone requests a
| code review from me, it notifies me on Slack. I don't know how
| anyone can tolerate a system that is this bad. It's like
| Microsoft made the product before they even bought it.
|
| My experience with all of this is that people don't file issues
| for things they're working on, don't close issues that span
| multiple PRs, don't reply to issues that require their attention
| (or even know what's assigned to them), and leave tasks 90% done
| because crucial followup gets forgotten after Github
| automatically closes an issue. This makes the system actively
| harmful -- at best, it's a dumping ground for ideas that will
| never be. If someone was going to do something, they'd just do
| it. If it goes into Github issues, it is only worth it for "I
| thought of an idea that will take a month to implement, here it
| is". Very bad.
|
| This doesn't even scratch the surface of what an issue tracking
| system can or should do, but is hopefully enough to convince you
| that it's totally useless. I don't know what issue tracking zen
| is, except that when I worked at Google their internal tool
| didn't have any of these problems.
|
| Linear (https://linear.app/) looks really nice. It's like someone
| took my exact ideas for how an organization should manage
| projects and made it into a computer program. It's speedy. It
| tracks exactly the right pieces of information. It lets you take
| a look at the company's progress towards its goals, across teams,
| with one click. You can operate it entirely with the keyboard. It
| has an inbox for everything that requires your specific
| attention. It understands the concept of issue triage. Really
| great tool. Miles ahead of Github issues (and the things that
| integrate with Github issues, like Zenhub).
| wereHamster wrote:
| How does what you used at Google compare to Linear?
| jrockway wrote:
| Not as good. Org-wide planning was totally out of scope, but
| hotlists were great for organizing cycles, quarters, triage,
| etc. Individuals had the ability to look at a hotlist and
| decide "what's the #1 thing to work on right now", which I
| guess is the most important thing. The tool also made a lot
| of mistakes that new tools don't -- separate severity and
| priority levels, canned resolutions ("working as intended"
| was a meme), etc.
|
| Avery has some thoughts on the system near the end of his
| Epic Treatise: https://apenwarr.ca/log/20171213#slide38
| ngrilly wrote:
| The software engineering at Northvolt Systems also switched to
| Linear.app and it's amazing.
| zestyping wrote:
| We recently switched from Trello (ugh! for many of the reasons
| you mentioned) to Linear and I'm loving it.
| TeMPOraL wrote:
| Nope.
|
| Having worked in a shop that used GitLab issues for project
| management, I've come to realize GitHub-style issue trackers work
| if all your project management boils down to creating and
| tracking bite-sized blobs of work. It stops being sufficient when
| you need to actually _plan ahead_. FWIW, so does Trello. Couple
| reasons why:
|
| - Issues are flat. Work breaks down into a tree. And no, "epic /
| ticket / checkboxes in task" is not enough, that's barely two and
| a half levels. Compare with
| https://en.wikipedia.org/wiki/Work_breakdown_structure [0].
|
| - Issues are independent. Properly broken down, work in a project
| has dependencies. That turns a tree of tasks into a _directed
| acyclic graph_ of tasks - work items depend on other items, often
| items from different areas in the WBS.
|
| - Issues don't schedule well. Most issue trackers I've seen don't
| support simultaneously entering planned start/end dates, actual
| start/end dates, and actual work being done. This means they
| can't be effectively used to estimate the length of the project,
| and update that estimate as the project progresses. Forget about
| any auto-scheduling.
|
| There's a reason why old-school PMs love their Gantt charts so
| much - they properly reflect the graph-like nature of work, and
| they let you see the information crucial for planning at a
| glance.
|
| In my opinion, any system that doesn't support entering DAGs of
| tasks with planned manual and automatic dates (e.g. "this task
| will take ~5 days, and starts when that other task ends"), and
| doesn't allow you to compute the critical path, is not a project
| management tool, but a glorified TODO list. A good PM tool does
| what I've outlined above, plus it lets you easily run _what-if
| analysis_ - that is, play around with estimates, resource
| availability, task ordering, to explore the space of possible
| project plans and possible failure modes.
|
| So, in my opinion, neither GitHub/GitLab issues, nor Trello or
| other Kanban boards, are useful for PM work. I've heard that
| properly configured Jira just might be. MS Project is a good one,
| if you ignore its clunky UI and propensity to randomly lock up
| for no reason.
|
| --
|
| [0] - Even where the Wiki says "For most projects a hierarchy of
| two to four levels will suffice.", this is in context of "lowest
| level of detail of the WBS should be longer than a single
| reporting period", which would be typically a month or more.
| Tickets in the issue tracker are thus _a level below that_. So,
| to properly break a project down, you need ~2-4 levels of
| structure _above_ your tickets.
| neilv wrote:
| I came to much the same conclusion (and kinda expected to), but
| I did find merits in the GitLab Issues approach.
|
| As an experiment this year, for a more reactive phase of
| engineering in the startup, I experimented with using GitLab
| Issues and Board to track all engineering & operations work.
|
| I redid the GitLab Labels to have two sets: Kanban state, and
| color-coded Urgency. Each issue had exactly one from each set.
|
| I used the "blocks/blocked-by" issue linking to do a crude and
| poorly-visualized approximation of Gantt task dependencies.
|
| For tracking periodic tasks that had a human in the loop (e.g.,
| run this daily data acquisition tool, spend 5 minutes actually
| checking the infrastructure dashboard, periodic offline
| backups), they stuck in the Doing Kanban column, and the Due
| Date changed to the next day they should be run. This worked
| well, except for one unexpected performance issue: the Issues
| page for a daily periodic task that included a daily commit and
| time spend, and occasion comment... was surprisingly slow to
| fully load (without measuring, after a few months, it was maybe
| up to 10 seconds, while all those event entries entries were
| being loaded). It often slows the daily task, which is
| something that makes people avoid/resent tools, but I imagine
| speeding it up might be viable.
|
| I also used the "/spend" in the Comments to track individual
| time spends. (I did the spends only myself, as an experiment; I
| don't know whether it would go over well with new hires,
| especially before we'd established unusual trust that it
| wouldn't be used for play-to-the-metrics nor against anyone.)
|
| The integration with CM workflow is a win for developers and
| project managers (whether or not they're the same people). The
| performance is so-so. (For example, one "urgency::
|
| What might make it really-really win for managing projects that
| are plannable (rather than situated action on a weekly basis)
| is a solid Gantt view on the same model, plus maybe adding just
| a little scheduling to the model.
|
| (If GitLab doesn't do it, this project management view could
| possibly be third-party integration wrt GitLab, like what
| Instagantt does as a layer over Asana. I'd almost suggest it to
| Instagannt, though hopefully a bit faster to use, so that
| project management isn't slowed by tool performance.)
| eezing wrote:
| Sounds like you spend a lot of time managing your PM tool.
| TeMPOraL wrote:
| Nah. There's not much to manage in a proper PM tool itself.
| But you have to know the basic concepts (like critical path)
| and understand the problem space (e.g. tasks form DAGs, not
| sequences). Also, project management is in big part planning
| the work, not doing the work. Issue trackers help with the
| latter, not the former.
| simonw wrote:
| "Issues are independent. Properly broken down, work in a
| project has dependencies"
|
| A trick I use a lot is to open a "tracking issue" and then link
| to it from other dependent issues by mentioning its #ID in
| those issue's descriptions.
|
| The tracking issue automatically shows the open/close status of
| those other issues, which means I can see at a glance if all of
| the dependent issues have been completed.
|
| Here's an example:
| https://github.com/simonw/datasette/issues/1105
|
| It's not nearly as sophisticated as what you're looking for in
| terms of date estimates and critical paths, but it does work
| well for light-weight dependency tracking.
| TeMPOraL wrote:
| We've done something like this too. It worked well to keep
| track of related issues, particularly during regular reviews.
| It turned out insufficient when we had to plan ahead for
| ~6-12 months of work on polishing "version 1.0" (~300
| existing tickets that needed to be pruned, reprioritized and
| otherwise rearranged) and building "version 2.0" (proper
| work-breakdown task of a complex project).
|
| Our PM tried to handle this challenge for a while, by writing
| scripts against GitLab API. This eventually turned out
| insufficient, so the PM, myself and another coworker set out
| to find a project management tool that actually does project
| management. It's after extensive discussions and search that
| we figured out none of the well-known work tracking products
| in software development fit the bill.
|
| Best easily-accessible options we've found were: MS Project
| (if you're on Windows, which we weren't), Jira (if you hire a
| person full-time just to manage it) and YouTrack from
| JetBrains (if you hire a person full-time just to script it).
| There are other options in the corporate PM space, but we
| didn't get to explore those as a startup (and eventually
| we've all left the company).
| gregd wrote:
| GitHub issues is great, until and unless you work for a company
| that doesn't allow 3rd party access to the Org where all your
| repos live. I want and need a one-stop shop for my Kanban board
| and I could accomplish this using GitKraken Boards for instance,
| but because of where I work, they disallow GitKraken access to my
| repo issues. So now, managing a dozen or more repos with an issue
| tracker for each one separately, is frankly, a pain in the ass.
| polote wrote:
| There is no way to move an issue from repository. And this is
| just one example.
|
| But I guess if trello was enough, it means you don't really have
| bigger needs than having a list of tasks.
|
| Stop assuming the thousands of companies which use Jira are
| stupid
| ricardobeat wrote:
| You seem offended at the thought that someone else doesn't
| value the tooling you use. Why is that? There is room for
| different approaches.
|
| FWIW, in my experience I haven't seen JIRA add anything besides
| overhead, regardless of how tidy a PM makes it.
| polote wrote:
| I hate JIRA. But if you are not a small organization, JIRA
| doesn't play in the same league as Github issues. Same as
| Notion and Confluence
| civilized wrote:
| I question the notion that JIRA is the only workable tool
| at large organizations. Many large organizations are full
| of small, relatively autonomous teams anyway, and those
| teams will benefit from a less bureaucratic tool.
| synunlimited wrote:
| Do you mean move an issue from one repository to another?
| Because that is totally possible now.
| polote wrote:
| You are right, I totally missed that
| simonw wrote:
| I've been doing this for all of my personal projects for a few
| years now and it works really well for me.
|
| GitHub Issues has exactly the set of features that I need. I'm
| confident I understand 100% of the functionality that it offers,
| and I use all of that functionality.
|
| (The "GitHub Projects" stuff hasn't stuck for me, but that's
| presented as an optional layer on top of issues so it's easy to
| ignore it.)
|
| I also love how programmable Issues are. The APIs (both REST and
| GraphQL) are easy to use, and the options for automation using
| GitHub Actions are exciting, though I've not done much with them
| yet.
|
| I also like having an exit plan for this kind of tool, and the
| API means I can easily get all of my issues data out again. I
| wrote a tool called github-to-sqlite which exports my data to
| SQLite and I use it to build a SQLite database that brings
| together data from many of my projects so I can search and query
| it in one place - demo here: https://github-to-
| sqlite.dogsheep.net/
| bhauer wrote:
| This issues-only approach, or what I call just task-tracking, is
| my favorite small-team development process. By small, I mean 2 to
| 8 people or so.
|
| I resonate with this blog entry because I agree that the
| visualizations that more sophisticated tools provide are low-
| value distractions that ultimately cause more problems than they
| solve. The most important thing for collaborative development, in
| my opinion, is a clear, accurate, singular definition of work to
| be done. From there, you can prioritize and adapt as needed, but
| spending inordinate amounts of time with visualizations (often to
| satisfy some non-technical stakeholders) is wasteful allocation
| of resource time.
|
| My own thinking on task trackers:
| https://tiamat.tsotech.com/task-tracking
|
| For example, a golden rule of mine is that you should only have
| one authoritative system used for task-tracking. Any additional
| system or tool will inevitably lead to confusion about priorities
| and lost efficiency, despite the appearances to the contrary that
| lead you to add a tool in the first place.
| lamontcg wrote:
| Be nice if the new GitHub issues got out of beta, it looks like
| that should be able to whittle down 90% of the use cases of
| Trello and Jira and be simple and usable for personal issue
| management.
| derefr wrote:
| Tangent, but:
|
| > or the macOS "Sticky Notes" app that somehow still exists in
| 2021
|
| Why _isn't_ Sticky Notes just a view into a particular folder in
| Notes.app, anyway?
| desert_boi wrote:
| I actually still use it all the time. Just a habit from when I
| started using what was then OS X in '08.
| derefr wrote:
| Oh, sure, I don't mean "why does this app exist"; I mean "why
| isn't its underlying data model merged/synchronized with that
| of the other OS note-taking app." Why can't I see my
| computer's Sticky Notes on my iPhone in Notes under "Sticky
| Notes - [Computer name]"? Why can't I _add_ a sticky note to
| my computer by putting it in such a folder?
| lstamour wrote:
| It might be that the future of sticky notes is Quick Notes
| as in iOS 15, but they do different things, I agree. Apple
| really should integrate the concept of sticky notes into
| both Notes and Reminders, to create a bit of a hybrid - a
| sticky note that can act as a reminder, etc. Even better
| would be sticky notes that reveal themselves when using
| certain macOS or iOS modes, so that when I'm at work I see
| my work stickies, and when I'm at home I could see some
| home stickies, etc. It should also be easy to remove a
| sticky by converting it permanently to a note or reminder,
| or maybe even a calendar event or contact.
| agustif wrote:
| I just wanted to say thanks for the blitz-saas (stripe branch)
| example repo from placemark creator.
|
| Wish you the best!
| mwcampbell wrote:
| Having to create issues-only repositories seems like a sign that
| one may be using the wrong tool. But the simplicity of GitHub
| Issues, and the fact that most issues on my plate _are_ related
| to a particular repo, makes it tempting.
| unethical_ban wrote:
| In a previous workplace, our security operations team
| (firewall) had several options for project tracking: Nothing,
| or Gitlab issues.
|
| Generically, we're talking "Kanban board" with swimlanes for
| the status, tags for categorization, and comments/attachments
| for discussion tracking.
|
| I'm currently in a position to get some people sync'ed on
| projects for a client, and I am going to recommend we use
| Trello.
|
| Kanban is just the right level of organization and visibility
| without going full agile-daily-standup-sprint overload.
| 5e92cb50239222b wrote:
| I find it to be unusable for projects of any decent size.
| There's pretty much zero visibility on what everybody else is
| doing, discussions are hard to use when they go over five
| comments (for example, you can't easily binary-search a large
| discussion with Home/End or my favorite vim-like navigation
| plugin, because you don't have the full page right away and
| it loads a few comments at a time). It's very JS-heavy and
| writes multiple gigabytes of data to localStorage every hour
| (which wears down my SSD needlessly) -- the only web
| application I've ever seen doing that. I can go on.
| tailspin2019 wrote:
| The parent mentioned two tools - which one is your comment
| about?
| nkozyra wrote:
| You don't really need this, though. Github has a project board,
| too, and it's ... pretty good!
|
| My gig is still in Trello-land and I'd like to move away from
| it but companies have a tendency to include biz folks in Trello
| whereas Github is scary tech world to a lot of them.
| judge2020 wrote:
| Worth checking out the new GitHub Issues beta:
| https://github.com/features/issues/
| pbiggar wrote:
| Signed up for it to use with darklang a few weeks ago but
| haven't heard anything - are they adding more people to the
| beta?
| imbnwa wrote:
| > Having to create issues-only repositories seems like a sign
| that one may be using the wrong tool.
|
| JIRA is a pile of bolted-on features, and no one has ever
| measured what is essential to project management, so this point
| strikes me as sort of an ad populum than an argument that JIRA
| or whatever is more fit for some PM task than Github Issues.
|
| This is what kills me about software project management, at
| least in Enterprise where I work: its about _people
| consistently communicating to one another_ ; that's it, lest
| there's something else we can extract as somehow more
| primordial. Somehow people consistently communicating over a
| topic has been reified to the point that we mistake the reified
| things for the thing-in-itself.
| simonw wrote:
| I don't see why that's a sign of the wrong tool: if it's OK to
| use a GitHub repo for code and not for issues, why not use one
| for issues and not for code?
|
| I drop a single README.md in the root of the repo that links to
| the issues and leave it at that.
| erhk wrote:
| Arguably any tool will eventually be hacked around to fit
| needs, unless you are the owner --in which case you just hack
| on the tool.
| rafaelturk wrote:
| That's how we operate: Issues only. Even legal and marketing use
| issues.
|
| ...In their ideal form, GitHub issues are homogenous. An issue is
| a task that you need to complete. If it isn't a task, it isn't an
| issue. If it's done, it's closed. If it's not done, it's open.
| quesodev wrote:
| Having run several engineering teams (15-20 people), I used this
| approach extensively. It meant one less place to go and one less
| tool to use. I liked this approach so much, I also wanted to use
| Github Issues for internal and external customer support instead
| of having another help desk tool involved. I created
| https://hubdesk.io/ as a side project to do this. Forward your
| support emails to HubDesk and it creates a Github issue for every
| email thread. You can then communicate back and forth with sender
| by starting a comment with "@reply" to send a reply email.
| codesternews wrote:
| Not related but your landing page is good. May I know what
| template/how did you build it. Thanks
| technics256 wrote:
| I'm not OP but I can spot these anywhere now. It's from
| www.tailwindui.com
| dan-robertson wrote:
| I think anything that reduces the number of different places
| that information or discussion may happen is good. The thought
| of having a mix of code/code review/wiki/other
| wiki/email/chat/list archives/jira/shared inbox/trello is not
| appealing to me. There's some continuum where adding a system
| changes things from good to annoying and I think my own
| feelings put that place more towards the "fewer systems" end
| than where other people put it.
| simonw wrote:
| Tool proliferation is definitely a problem, but at larger
| organizations I'm not sure how feasible it is to keep
| everyone using the same small set of tools.
|
| At my last large employer I ended up putting together a
| custom search engine that searched across a bunch of
| different places where important stuff ended up - Google Docs
| and GitHub Wikis and Markdown-in-GitHub and Confluence and
| Salesforce Support and a mailing list archive and a few
| others.
|
| Having a single place to search really helped: I had thought
| that we had bad documentation, but it turned out we actually
| had pretty good documentation just distributed across too
| many different places.
| zikzak wrote:
| We used to use Unfuddle for source control and issues/PM
| then went to self hosted TFS but kept issues and pm in
| Unfuddle. Then we decided that was working so well for Dev,
| everyone should use it. But people didn't like Unfuddle. So
| now we have Asana. Everyone but Dev likes it, there's no
| ticket numbers, and it's confusing but at least the
| stakeholders are using it?
| royandre wrote:
| We have made a solution for assigning task numbers in
| Asana. Will prioritize us posting how do add it.
| [deleted]
| mwcampbell wrote:
| HubDesk looks nice. A couple of questions though:
|
| 1. Would I have control over the "From" name and address for
| emails that HubDesk sends to users?
|
| 2. Do email replies from users get added as comments on the
| issue?
|
| 3. When an issue is created, does HubDesk send a confirmation
| to the user so they can do follow-up replies even before the
| rep has done an outward-facing reply?
| ExtraE wrote:
| #1 and 2 are both very important.
| pininja wrote:
| In case you like this TL;DR, the author expands on their GitHub
| practices here https://github.com/tmcw/github-best-
| practices#issues--milest...
| arendtio wrote:
| Funny how Microsoft Project isn't even mentioned, but Excel
| instead...
|
| I still have to come across a project management software that is
| delightful and effective at the same time. There are many tools
| out there, that do one job very good, but in my opinion, none
| that combine planning, execution and evaluation in a modern and
| predictive fashion.
| bbertelsen wrote:
| Apologies for off-topic: Does anyone recognize the blog
| platform/theme being used?
| bob1029 wrote:
| We've been doing this for our product for the last ~4 years. It's
| amazing. Getting close to 10000th issue. All the code for the
| whole stack lives in the repo too, so the links between
| code/pr/issue are flawless.
|
| I think we still want to build another layer on top that is more
| about how our business works, but GH issues would continue be the
| one-stop-shop for anything regarding the codebase itself.
| agustif wrote:
| Linear.app is a great alternative to JIRA and connects also to
| Git providers.
| robertwt7 wrote:
| I actually really liked this approach compared to having to
| switch to jira/notion everytime.
|
| I think some big names are using this approach to right. Like
| aspnetcore and some other microsoft products
| ac50hz wrote:
| +1 Whilst I still use other tools too, Github Issues-only can
| help provide useful focus by limiting the options available to
| PMs and others.
| ttoinou wrote:
| Same for me, but with Gitlab Issues !
| christophergs wrote:
| Yep, I do the same. I also combine with github wiki for larger
| projects and documentation (often these will reference a bunch of
| issues).
| bredren wrote:
| Me too. I haven't tried jamming sales into issues but for
| product dev it is all issues and wiki for docs.
|
| I also use high med low customer impact and low med high
| difficulty labels as advocated by yc to organize priority.
| erhk wrote:
| There are a plethora of reasons not to put sales data into github
| issues. I appreciate the idea of reducing complexity. Focusing
| things around issue tracking gives a good workflow for opening
| and closing, and also provids a finite goal, but theres often
| needs which cannot be met.
|
| I also dont think that its necessary to point out but I would not
| advise handing over all business organizing to github as a
| platform.
| mlosgoodat wrote:
| > There are a plethora of reasons not to put sales data into
| github issues.
|
| Thanks for the details.
|
| Anecdotally; the author of the blog post and work environments
| I've been in did just that and ... reality still exists.
|
| Me thinks personal opinions on how to store data are ...
| personal opinions.
| simonw wrote:
| Is your concern that GitHub employees might access your
| confidential sales data if it's in issues in a private
| repository?
|
| Because if you're worried about that, there's probably a whole
| bunch of even worse things that they could be doing with access
| to your source code, secrets and CI infrastructure.
| wereHamster wrote:
| > handing over all business organizing to github as a platform.
|
| GitHub is not the only issue tracker. Git itself is the easiest
| to migrate off of GitHub, issues is probably close next.
| wingmanjd wrote:
| We're planning a migration from Atlassian suite to the Gitlab
| ecosystem, but one item that I can't seem to replicate is the
| issue/ ticket workflow of a JIRA ticket. We have a semi-involved
| workflow that covers most of the software development lifecycle:
| initial requirements gathering, approvals, coding development,
| code reviews, UAT approvals, prod deployment approvals etc.
|
| How do you handle this sort of thing with just Git(hub|lab)
| issues?
| lexs wrote:
| Scoped Labels (extended Kanban basically) and different boards
| for planning and development is our approach in gitlab
| sp1rit wrote:
| One issue I still have with github (issues) is, that they only
| allow a very small set of file types to be uploaded.
|
| You can get around this by gzipping everything, because they
| allow .gz, however I still don't see why I'm not allowed to
| upload .diff or .patch files.
| antipaul wrote:
| I wish. I'm at Big Corp where key project collaborators and
| stakeholders are wildly non technical and there's no way to use
| GitHub issues.
|
| They mostly use only email.
|
| What is a more accessible alternative?
|
| I've been trying google docs. Thoughts?
| enra wrote:
| We have been building https://linear.app which is both used by
| technical and non-technical folks
| orcasushi wrote:
| I am sometimes thinking about use master branch of my repo and
| add a folder called 'tickets'. Then in this folder create issues
| as markdown files. Use some Vscode, Emacs or Vim plugin to
| automatically number these markdown files and present comments as
| lists.
|
| No more dependency on online saas tooling and you can use the
| search option of your ide / os / command-line to search through
| them.
| dreamcompiler wrote:
| I'd love to use this approach if only I could save issues in, you
| know, git. Which isn't tied to Github.
| dboreham wrote:
| I've used this approach with success on work projects in the past
| and still use it for my "personal kanban". Nice of Microsoft to
| provide this facility for free.
___________________________________________________________________
(page generated 2021-08-21 23:00 UTC)