# issue tracker A software-development work-tracking system for recording, discussing, and managing bugs, enhancements, and other project requests. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How we closed 1,500 GitHub issues in one month DevFeed: [How we closed 1,500 GitHub issues in one month]() Original publisher: [Read original article]() Author: Marcos Hernanz Published: 2026-09-04T04:00:00Z Content type: article Language: en Sources: [Next.js Blog]() Topics: [GitHub Issues](), [Next.js](), [AI-assisted coding](), [issue tracker](), [Maintainers](), [bug]() Tags: [agent](), [ai](), [bug](), [github-issues](), [issue-tracker](), [maintainers](), [next-js](), [sandbox](), [vercel]() ### AI overview The Next.js team describes using an AI research agent to help maintainers review an issue backlog, close outdated reports, and retain issues that still matter. ### Source excerpt How the Next.js team used an agent to research old reports and work through the issue backlog. ## Treating Issue Bodies as Untrusted Input DevFeed: [Treating Issue Bodies as Untrusted Input]() Original publisher: [Read original article]() Author: Philipp Lehmann (philipp.lehmann@gruppe.ai) Published: 2026-08-14T07:00:00Z Content type: tutorial Language: en Sources: [Philipp Lehmann]() Topics: [prompt injection](), [GitHub](), [JSON Feed](), [Structured-data](), [issue tracker]() Tags: [agents](), [github](), [implementation](), [issue-tracker](), [json](), [llm](), [prompt-injection](), [schema](), [security](), [test]() ### AI overview The article explains how GitHub issue bodies can carry prompt injection attacks when an agent treats public input as instructions. It recommends fencing untrusted text, clearly labeling it, constraining model output to a fixed JSON action schema, and testing the validation boundary without a live model. ### Source excerpt Prompt injection via GitHub issue bodies: fence untrusted text and accept model output only as a fixed JSON action schema, tested without a model. ## Fact-checking PagerDuty's Opsgenie alternatives comparison table DevFeed: [Fact-checking PagerDuty's Opsgenie alternatives comparison table]() Original publisher: [Read original article]() Author: Tom Wentworth Published: 2026-07-28T14:21:14Z Content type: opinion Language: en Sources: [The incident.io Blog]() Topics: [incident](), [incident management](), [Incident response](), [Slack](), [Artificial Intelligence](), [dashboards](), [Microsoft Teams](), [API](), [Terraform](), [issue tracker]() Tags: [ai](), [api](), [article](), [comparison](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [microsoft-teams](), [outage](), [post-mortem](), [slack](), [slack-incident](), [terraform]() ### AI overview The article fact-checks PagerDuty's comparison table for Opsgenie alternatives, arguing that its description of incident.io is inaccurate. It presents incident.io as an end-to-end AI incident management platform with on-call scheduling, alert routing, incident response, dashboards, mobile access, status pages, investigation, post-mortems, insights, workflow automation, API access, and Terraform support. ### Source excerpt PagerDuty published a new comparison table about incident.io. Once again, it describes a product we don't recognize. So once again, we're correcting the record, row by row, with receipts. ## The Label as Contract: Consent and Priority as the Whole Queue DevFeed: [The Label as Contract: Consent and Priority as the Whole Queue]() Original publisher: [Read original article]() Author: Philipp Lehmann (philipp.lehmann@gruppe.ai) Published: 2026-07-28T07:00:00Z Content type: tutorial Language: en Sources: [Philipp Lehmann]() Topics: [issue tracker](), [audit trail](), [coding]() Tags: [agents](), [audit-trail](), [consent](), [fifo](), [issue-tracker](), [priority](), [security]() ### AI overview The article argues that an autonomous coding agent should act only on issues carrying a specific human-applied label. Free-form issue content is unauthenticated and cannot establish consent or priority; label actions provide an independent audit trail, and priority should be derived from label transitions. ### Source excerpt agent-ready label as the only consent gate for a coding agent: FIFO order by label time and a re-read-then-swap claim so two runs never share an issue. ## Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests DevFeed: [Triaging at Scale: How the Gradle Team Handles Issues and Pull Requests]() Original publisher: [Read original article]() Author: Vlad Chesnokov Published: 2026-07-16T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [issue tracker](), [GitHub](), [Automation](), [pull-requests]() Tags: [automation](), [bug](), [documentation](), [github](), [gradle](), [issue-tracker](), [pull-requests](), [usability]() ### AI overview The Gradle team explains how it triages GitHub issues and pull requests at scale. The article describes lessons from using and then removing stale-issue automation, the role of human review, and how issue reports help identify bugs, documentation gaps, and usability problems. ### Source excerpt Communities are at the heart of Gradle's success. Without their involvement, the build tool would not have the extensive feature set and wide use it has. And using the plural form is no mistake! While the user community is the largest, we also have a community of plugin authors that contribute to extending the capabilities of Gradle. A significant part of interactions between the Gradle team and those communities occurs via feature requests and bug reports using GitHub's issue tracker. Over the past years, we have improved how we handle those reports. We can now give them the attention they deserve and use them to help us improve the build tool across releases. In this post, we'll walk through how triage works today, the changes that got us here, and what you can do to help us help you when you report an issue. An iterative process Back in 2020, we introduced a stale bot to tackle our growing backlog of stale issues. Once it started closing issues, the community feedback was quick to arrive. The biggest complaint was that issues were closed automatically as stale, without a human from the engineering team ever weighing in. So we walked the automation back, step by step. First, we changed the stale bot to no longer close issues, only mark them stale and leave them open for the team to review. Then we reviewed all open issues carrying that label. With the backlog under control, we removed the stale bot for issues altogether. Later, we even re-triaged the closed stale issues that had at least one vote. Most turned out to be duplicates or already fixed. Today, no automation can silently close an issue. What's more, we don't miss any comments under closed issues: if somebody comments on a closed issue, it will be re-triaged. There are still around a thousand issues in our main repository closed by the stale bot. We don't plan to re-triage them, assuming they are obsolete. If the stale bot closed an issue you still care about, just leave a comment and we'll take another l ## Mac Native Builds, Live Protocols, And Open Issues Under 350 DevFeed: [Mac Native Builds, Live Protocols, And Open Issues Under 350]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-05T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [WebSocket](), [GraphQL](), [gRPC](), [issue tracker](), [API](), [Feathers](), [Java]() Tags: [api](), [electron](), [framework](), [integration](), [issue](), [mac]() ### AI overview Codename One reports that its open issue count fell to 332 after reviewing older tracker reports. The weekly update also covers native Mac builds, WebSockets in the core framework, gRPC and GraphQL integration, a new advertising API, and richer background work. ### Source excerpt The open issue count dropped below 350 after a push through the oldest reports, and the same week brought native Mac builds, WebSockets in the core, gRPC and GraphQL integration, a new advertising API, and richer background work. ## 130 Release-Roadmap Issues, 818 Agent Runs: A Mid-Iteration Reality Check DevFeed: [130 Release-Roadmap Issues, 818 Agent Runs: A Mid-Iteration Reality Check]() Original publisher: [Read original article]() Author: Eugene Petrenko Published: 2026-04-28T00:00:00Z Content type: article Language: en Sources: [Eugene Petrenko]() Topics: [AI Agent](), [Claude](), [codex](), [Artificial Intelligence](), [issue tracker](), [Orchestration](), [Command-line interface](), [Graphs](), [Requirements]() Tags: [agent](), [agents](), [ai](), [ai-agent](), [ai-agents](), [ai-coding](), [cli](), [code](), [eugene-petrenko](), [graph](), [issue-tracker](), [jonnyzzz](), [mcp](), [mcp-steroid](), [multi-agent](), [orchestration](), [pipeline](), [requirements](), [run-agent](), [tag-41199d53f463]() ### AI overview The article describes using a swarm of Claude, Codex, and Gemini agent CLIs to research 130+ release-roadmap issues and produce implementation specifications. The process used 818 agent runs over four days at an approximately $576 cost, followed by a mid-release comparison of the research with the team's actual work. ### Source excerpt We turned one release's roadmap -- 130+ umbrella-epic issues -- into fully-researched implementation specs using a swarm of three different agent CLIs (Claude, Codex, Gemini): 818 runs, ~155M+ tokens, ~$576, four days. Then, mid-release-cycle, we ran a snapshot to compare the research against reality -- with no expectation that anything was "done" yet. Here is the pipeline, the numbers, and the honest verdict. ## An open-source spec for orchestration: Symphony DevFeed: [An open-source spec for orchestration: Symphony]() Original publisher: [Read original article]() Author: Caleeeb - Follow Published: 2026-04-27T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [Orchestration](), [AI-assisted coding](), [codex](), [Open Source](), [issue tracker](), [pull-requests](), [coding](), [Software](), [systems]() Tags: [agentic](), [agents](), [code](), [codex](), [coding](), [engineering](), [issue-tracker](), [open-source](), [orchestration](), [pull-requests](), [web](), [workflow](), [workflows]() ### AI overview This article explains Symphony, an open-source specification and agent orchestrator created to reduce context switching in coding-agent workflows. Symphony connects project-management issue trackers to continuously running agents, while humans review the results. The article describes the workflow changes behind the system and reports a 500% increase in landed pull requests on some teams. ### Source excerpt Learn how Symphony, an open-source spec for Codex orchestration, turns issue trackers into always-on agent systems--boosting engineering output and reducing context switching. ## Trace similarity systems on top of ClickHouse to analyze crash stack traces from our CI DevFeed: [Trace similarity systems on top of ClickHouse to analyze crash stack traces from our CI]() Original publisher: [Read original article]() Author: Misha Shiryaev Published: 2025-09-24T12:46:35Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [ci](), [Traces](), [issue tracker](), [Fuzzing/Fuzz testing](), [FIRST]() Tags: [ci](), [clickhouse](), [crash-reporting](), [fuzzing](), [github](), [issue-tracker](), [logs](), [trace]() ### AI overview This article explains how to build a trace similarity system on top of ClickHouse to analyze crash stack traces from CI. It describes collecting crash reports, extracting stack frames, grouping similar traces, and creating or updating GitHub issues so teams can distinguish new bugs from known ones. ### Source excerpt Learn how our engineering team cut through noisy CI crash reports with a trace similarity system built on ClickHouse. ## How a transitive dependency caused unexpected Android behavior DevFeed: [How a transitive dependency caused unexpected Android behavior]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2025-01-14T00:00:00Z Content type: opinion Language: en Sources: [Posts on Marco Gomiero]() Topics: [Android](), [Library](), [issue tracker](), [navigation]() Tags: [android](), [bugs](), [debugging](), [dependencies](), [fragments](), [issue-tracker](), [libraries]() ### AI overview The author recounts debugging a crash affecting some Android users and tracing unexpected behavior to a change introduced by an external library. The article advises checking library changes and transitive dependencies during updates. ### Source excerpt This article is just a short "rant" and a "therapy session" to remind and warn my future self. I was recently debugging a weird crash affecting some users. The issue was related to navigation, fragments, and backstacks. After weeks spent trying to reproduce it, reading online reports, and cross-referencing previous libraries and SDK updates, I finally had an illuminating moment after reading about a similar behavior in the Google Issue Tracker. It made me wonder: Could something have changed in the Android Manifest? ## Keycloak DevDay 2025 Pre-Conf Event Announcement DevFeed: [Keycloak DevDay 2025 Pre-Conf Event Announcement]() Original publisher: [Read original article]() Author: Sebastian Rose Published: 2024-10-25T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Hackathon](), [Keycloak](), [Development](), [Documentation](), [issue tracker]() Tags: [2025](), [announcement](), [code](), [community](), [documentation](), [event](), [hackathon](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [saml](), [sso]() ### AI overview Keycloak announces a hackathon held before DevDay 2025, inviting contributors to work on code, documentation, translations, issue tracking, and community projects. The article provides the event schedule and explains how participants can join. ### Source excerpt Keycloak DevDay 2025 is just around the corner, and we would like to invite you to a special pre-event: the Keycloak Hackathon! Hackathon: actively help shape Keycloak On the day before DevDay, on March 5, our hackathon will give you the opportunity to actively contribute to the further development of Keycloak. Whether you write code, work on the documentation, improve translations or maintain issues in the issue tracker - everyone can take part. The hackathon offers you the opportunity to pitch new ideas and work together in small groups on exciting projects. Schedule of the hackathon 10:00: Start of the first iteration with a pitch round. Here you can present your ideas and topics, ranging from new features and bug fixes to documentation improvements. The teams start working on the pitched topics. Our goal is to achieve measurable results by the end of the day - be it through code contributions, documentation or other important improvements for the Keycloak community. 12:30: Lunch-break 13:30: Another start for everyone arriving later in the day. 17:00: Closing with presentation and honouring the results Why should you participate? The hackathon is a great opportunity to network and actively participate with other members of the Keycloak community. It's the perfect chance for: Participants arriving early who want to make good use of the previous day. Experienced contributors and maintainers who want to advance their projects or work on new topics. Newcomers who want to contribute for the first time and get involved in the community - whether through code, documentation or organisational tasks. Ideas and topics If you have an idea or a topic that you would like to work on at the hackathon, get in touch with us! We will be happy to support you with the preparation and help you present your topic successfully. If you would like to work on a topic but don't yet know exactly what you would like to take part in, please let us know. We try to organize teams and topics at ## Introducing "Active Community Members" DevFeed: [Introducing "Active Community Members"]() Original publisher: [Read original article]() Published: 2024-05-14T00:00:00Z Content type: article Language: en Sources: [postmarketOS Blog]() Topics: [Maintainers](), [issue tracker](), [GitLab](), [Authorization](), [Repository]() Tags: [community](), [gitlab](), [issue-tracker](), [maintainers](), [permissions](), [postmarketos](), [repository](), [team]() ### AI overview postmarketOS introduces an Active Community Members group to give experienced contributors more responsibility for issue triage and package merge-request approvals. Members need GitLab activity and two-factor authentication, while the group receives reporter permissions on the pmaports repository. ### Source excerpt The call for Trusted Contributors we put out in December (and part 2) has been successful beyond our wildest imagination. As of writing we now have 11 TCs, who make a huge impact regarding the amount of patches we get into postmarketOS and the issues that get answered. We have learned that a great way to scale postmarketOS up is empowering well known community members to just do what they care about in this project. With today's blog post we want to cut some more red tape. Besides the Trusted Contributors, we have a whole lot more active community members that are either listed in CODEOWNERS or just have been very active in the issue trackers. Permissions We figured that it would be immensely useful if those very valued members of our community would be able to: Triage issues by applying labels, and being able to close them. Approve merge requests to packages that they maintain. The big difference to the Trusted Contributor role is, that Active Community Members do not need to submit a formal application, and that they don't get merge rights. How it will work You must have 2FA enabled on your GitLab account. If you have your name in the pmaports CODEOWNERS file and have been active on GitLab within the last three months, expect an invite to a new "postmarketOS Active Community Members" GitLab group over the coming weeks. If you are not in CODEOWNERS, but you do help out a bunch with pmaports issue triage (which should be obvious from your GitLab activity) and would like to do this more effectively, then you can also join this group. Write a short e-mail, mentioning your gitlab nickname and that you would like to join the Active Community Maintainers. The new Active Community Members group gets reporter permissions on the pmaports repository. Improving the triaging process itself is currently being discussed in #60 and further feedback is appreciated. The current iteration of labels and how they are meant to be used can be found in the triaging wiki article. Groups o ## Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST DevFeed: [Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-02-02T17:02:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [Chromium](), [issue tracker](), [migration](), [Google](), [Open Source](), [Documentation]() Tags: [bugs](), [chromium](), [documentation](), [google](), [issue-tracker](), [migration](), [none](), [open-source](), [tooling]() ### AI overview Chromium is migrating all issues, including their history and stars, from Monorail to the Google-powered Chromium Issue Tracker. The migration is scheduled for February 2-4, 2024, with existing issue links redirecting afterward and documentation for common workflows to be added later. ### Source excerpt As we shared last year, Chromium is moving to a different issue tracker to provide a well-supported user experience for the long term. Migration is beginning today (February 2, 2024) at 5pm PST. We expect migration will be completed by the end of day (PST) February 4, 2024. What's happening We will migrate all Chromium issues, including issue history and stars, from Monorail to a different tool: Chromium Issue Tracker, powered by the Google Issue Tracker. This tooling change will provide a feature-rich and well-supported issue tracker for Chromium's ecosystem. Chromium will join other open source projects (Git, Gerrit) on this tooling. Existing transparency levels to bugs will be maintained. Post-Migration We will publish another post once the migration is complete. Once the migration completes, existing Monorail issue links will redirect to the migrated issues in the new issue tracker. We will prioritize feedback to continue to improve the issue tracker experience. Documentation on new and common workflows will be added to chromium.org once the migration is complete. Help & Feedback You can reach out at any time to issue-tracker-support@chromium.org with questions or concerns. ## This Week at Zed Industries: #5 DevFeed: [This Week at Zed Industries: #5]() Original publisher: [Read original article]() Author: Max Brunsfeld Published: 2023-06-02T00:00:00Z Content type: article Language: en Sources: [Zed Industries - Blog]() Topics: [ui](), [App](), [dashboards](), [issue tracker](), [systems]() Tags: [app](), [features](), [issue-tracker](), [layout](), [os](), [screen](), [set](), [view]() ### AI overview Zed's weekly update covers the release of Zed 0.88, including a redesigned panel system and a zoom feature. It also describes crash problems after release, three patches issued to address them, new crash dashboards, and ongoing work on LSP server detection. ### Source excerpt Panels, panels, and more panels... ## Gradle Public Roadmap DevFeed: [Gradle Public Roadmap]() Original publisher: [Read original article]() Author: Piotr Jagielski Published: 2022-06-17T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [GitHub](), [releases](), [issue tracker](), [Slack]() Tags: [github](), [gradle](), [issue-tracker](), [release-notes](), [releases](), [slack]() ### AI overview Gradle has made its Build Tool roadmap public through a GitHub-hosted roadmap board. The board presents planned projects and user-facing features by quarter and target release, while also showing work delivered in the previous two quarters. ### Source excerpt We are excited to announce that the Gradle Build Tool roadmap is now public. See the roadmap board and the associated readme. Motivation The Gradle Build Tool project regularly ships new releases full of new features and bug fixes. So far our main channels of communication with the user community to share plans and get feedback were release notes, blog, issue tracker, forums, and community Slack. However, we lacked a high-level overview of what's planned in the upcoming releases. About the roadmap Today, we are announcing our new roadmap board hosted on GitHub. It lists major projects and user-facing features, organized by quarter and target release. The board also shows the past two quarters so that you can see what we delivered in recent Gradle releases. Each roadmap item provides a brief description and links to related issues in the issue tracker. Share Your Feedback We hope that this additional level of transparency about our plans will be useful to you. Please let us know if you have any questions or feedback. Comments on the roadmap board itself are disabled to keep it neat and tidy. Instead, reach out to us on the community Slack #roadmap channel. ## incident.io on Ship It! DevFeed: [incident.io on Ship It!]() Original publisher: [Read original article]() Author: Chris Evans Published: 2021-10-04T00:00:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [incident](), [incident management](), [issue tracker](), [Server](), [ssh]() Tags: [core](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [issue-tracker](), [outage](), [podcast](), [post-mortem](), [slack-incident]() ### AI overview The article discusses incident.io's approach to incident management, combining opinionated defaults such as incident leads, severity definitions, and structured updates with flexibility for each company's process. It emphasizes simplicity and reducing operators' decision-making burden during incidents. ### Source excerpt A few weeks ago, Stephen and I had the pleasure of talking to @Gerhard on changelog's Ship It! Podcast. We chatted about incident workflows, our relentless focus on simplicity, and how incident.io uses incident.io when we have incidents ourselves. ## postmarketOS in 2020-11: Edge & Donations DevFeed: [postmarketOS in 2020-11: Edge & Donations]() Original publisher: [Read original article]() Published: 2020-11-30T00:00:00Z Content type: news Language: en Sources: [postmarketOS Blog]() Topics: [Development](), [bug](), [issue tracker](), [Git](), [Protocol (disambiguation)](), [upgrade](), [Pine64]() Tags: [bug](), [development](), [git](), [infrastructure](), [issue-tracker](), [pine64](), [postmarketos](), [protocol](), [upgrade]() ### AI overview The November 2020 postmarketOS update reports a crash caused by an Alpine edge wlroots upgrade, explains how developers traced the issue with git bisect, and describes a temporary revert while Phosh aligned with the API protocol. It also announces donation support and funding for continued postmarketOS development and infrastructure work. ### Source excerpt Here is the promised second part of the November 2020 update. The other half is here if you missed it. News section for the 'edge' channel Two weeks ago, a wlroots release was pushed to Alpine that caused Phosh to crash. This is a good example of things that can go wrong when using the edge channel of postmarketOS (as opposed to stable). The bug was reported to the postmarketOS issue tracker (precisely the right move!) and within the next eight hours until we could close that issue, it was pinned down to the wlroots 0.12.0 upgrade, Phosh developers were informed, log messages were analyzed but were not useful and eventually the "offending" commit was found with git bisect. It turned out that the commit was a feature and not a bug, it made wlroots terminate connections if some API protocol was not followed as intended whereas it would just ignore this previously. An issue was created in the Phosh tracker, and a patch was submitted to Alpine edge to revert that specific commit until Phosh follows that specific API as it was intended (likely soon). The story told above was certainly not worth writing a regular blog post about, it was so quickly resolved that if each time we dealt with issues like these it would be hard to find the proper blog posts among these edge breakage reports. But still, it would be nice if there was something like a second blog where people running postmarketOS edge can quickly find information about such issues while they are ongoing. This is implemented now, find it at postmarketos.org/edge. Donations Time and again, we were asked if we accept donations. Today we are happy to announce that all the paper work is done. Yes, we are ready for donations! Depending on where you live, the donation is tax deductible. A variety of payment methods are available: from bank transfer to Bitcoin, Bitcoin Cash, Namecoin, PayPal and credit card. If you have an account set up for any of these already, it should only take you a few minutes. PINE64 used this mec ## Find that bug! Using a search engine as a programmer DevFeed: [Find that bug! Using a search engine as a programmer]() Original publisher: [Read original article]() Author: Itamar Turner-Trauring Published: 2020-08-17T00:00:00Z Content type: tutorial Language: en Sources: [Itamar Turner-Trauring]() Topics: [Programming](), [issue tracker](), [Python](), [Stack Overflow](), [pandas](), [Logging](), [GitHub](), [JSON]() Tags: [bug](), [documentation](), [github](), [issue-tracker](), [json](), [pandas](), [python](), [search]() ### AI overview This article explains how programmers can find solutions to bugs and programming problems by searching project-specific issue trackers, documentation, Stack Overflow, and other local resources alongside general search engines. It uses an Eliot and Pandas error as an example of a GitHub issue that a general search engine did not index. ### Source excerpt Most bugs you encounter have been encountered by others before you; most programming problems you face have been faced by others as well. And many of those people have written down details about what they've learned--in issue trackers, documentation, and blog posts. All you have to do is find this information. Typing a phrase in to your search engine of choice will sometimes take you straight to the right answer. But quite often, the results aren't helpful. No need to give up, though: there are still plenty of ways you can productively keep searching. Use site-specific search too It's easy to believe that search engines have all the answers right at the top, but they actually hide quite a lot of content deep in their results. And some obscure content never gets indexed at all, which is unfortunate when it's the obscure content that you need to find. So instead of just using a search engine, use the local search engine of the project issue tracker, the documentation, StackOverflow, and so on. For example, let's saying you're using Eliot, a somewhat obscure Python logging library I maintain, and you want to use it with the Pandas library. Unfortunately, you get an error, so you search Google for the text of the error: eliot dataframe is not json serializable. Now, there is an actual issue in Eliot's GitHub issue tracker with this exact error message--but as of August 2020 Google doesn't return it, probably because it didn't bother to index that page. But if you were to use the search form on the Eliot GitHub project's issues page, you would find the issue that mentions this particular error. In this case, as in many others, the search engine isn't actually indexing everything: you have no choice but to use the local search engine. Local search engines often have the additional benefit of allowing more structured search, for example: An issue tracker might let you search by open/closed status, labels, or the affected version. StackOverflow questions are tagged with parti ## covidnearme.org: A local COVID-19 case-tracking website DevFeed: [covidnearme.org: A local COVID-19 case-tracking website]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2020-03-13T00:00:00Z Content type: release Language: en Sources: [Scott Johnson]() Topics: [Website](), [data](), [GitHub Issues](), [issue tracker]() Tags: [announce](), [covid](), [covid-19](), [covidnearme](), [covidnearme-org](), [data](), [github-issues](), [issue](), [tool](), [web]() ### AI overview The article announces covidnearme.org, a website intended to help users view local COVID-19 case information, bookmark locations, and see a leaderboard of cases. It also describes plans to track metrics such as deaths and recoveries and report bugs through GitHub Issues. ### Source excerpt I'd like to say that I'm happy to announce: https://www.covidnearme.org/ but I'm not. Like a lot of us, nay, most of us, I find the current COVID-19 / Corona virus bothersome if not scary. But the world is what it is and we are better off knowing more about COVID-19 rather than less so I made a tool. What is covidnearme.org? Covnearme.org is a web site which lets you: Easily drill down to where you live. Bookmark a location or location that you care about See a leaderboard of cases BUT WHAT HAPPENED IN THE US ON 3/10? That is apparently the date when Johns Hopkins stopped reporting US level county data and only data at the state level. Yes that means that the US is officially LESS OPEN than China. Let's compare a screenshot between Seattle and Hubei: If you think this is the same bull crap that we do then please use this hashtag when you tweet: #hopkinswheresmylocaldata #Covid_19 Where's the Damn Map? We didn't put one in (yet). I've been using the Hopkins tracker for several weeks now and it gives me a great feel for the global scene but I don't just want global - I want local. And I'm too damn fat fingered to make their map work for me easily. Why Did You Build This? We wanted: The ability to know what's happening near the people we love. The ability to bookmark a location - our homes, our parent's homes, our friends workplaces The ability to know metrics which people aren't posting yet like the death metrics (why the hell is Italy so much higher?) and the recovery metrics (Seattle has a lot of cases but the recovery percentages are pretty good) How Do I Give You Bugs? We have setup a public github repo for this to capture bugs as github issues. Just file an issue and please, please, please give us the url to where you have issues. Goto: https://github.com/fuzzygroup/covdidnearme_bugs/issues Note: If anyone out there in the bug tracking world wants to give us tooling for bugs, contact fuzzygroup at gmail.com Who the Hell Are You? You keep saying we. Who is we? The ## Contributing Code Samples To Kotlin Documentation DevFeed: [Contributing Code Samples To Kotlin Documentation]() Original publisher: [Read original article]() Author: Adam McNeilly Published: 2020-02-24T00:00:00Z Content type: tutorial Language: en Sources: [Android Essence]() Topics: [Kotlin](), [Documentation](), [Open Source](), [issue tracker](), [GitHub]() Tags: [beginner](), [contribute](), [documentation](), [github](), [issue-tracker](), [kotlin](), [library](), [open-source]() ### AI overview A beginner-friendly tutorial explains how to contribute code samples to Kotlin's standard library documentation. It covers finding suitable tasks in YouTrack, reviewing contribution guidelines, forking and building the repository, locating functions without samples, and beginning a Vetoable example. ### Source excerpt The Kotlin language used by Android developers all over the world is open source and available on GitHub. This means it's open for contributions from anyone! It may, of course, feel very intimidating to contribute to a project of that size. Especially for those of us who are new to open source contributions. The JetBrains team makes this process a lot less scary than it sounds. There are some beginner friendly ways to contribute to the language, and this post will walk you through every step. ## Complementary engineering indicators DevFeed: [Complementary engineering indicators]() Original publisher: [Read original article]() Author: Dave Cheney Published: 2019-12-04T09:46:26Z Content type: opinion Language: en Sources: [Dave Cheney]() Topics: [Development](), [issue tracker](), [Statistics](), [Software]() Tags: [development](), [engineering](), [issue-tracker](), [metrics](), [small-ideas](), [software-delivery]() ### AI overview The article discusses using complementary engineering indicators to assess software project health. It describes tracking delivery date, completeness of promised work, and defects reported, while noting that optimizing one measure can negatively affect another. ### Source excerpt Last year I had the opportunity to watch Cat Swetel's presentation The Development Metrics You Should Use (but Don't). The information that could be gleaned from just tracking the start and finish date of work items was eye opening. If you're using an issue tracker this information is probably already (perhaps with some light data [...] ## Slack and the false sense of urgency DevFeed: [Slack and the false sense of urgency]() Original publisher: [Read original article]() Author: Hadi Hariri (mail@hadihariri.com) Published: 2018-12-16T23:00:00Z Content type: opinion Language: en Sources: [Hadi Hariri]() Topics: [Slack](), [issue tracker](), [context]() Tags: [issue-tracker](), [jetbrains](), [productivity](), [remote](), [slack](), [team]() ### AI overview The author argues that Slack reduces internal email but can create a false sense of urgency, frequent interruptions, and context switching. They recommend using Slack primarily for urgent questions, while directing non-urgent discussions and bug reports to email or an issue tracker. ### Source excerpt Slack brought us the promise of reducing emails and having all the knowledge of your company in one place, searchable. While I still feel it's completely failed to deliver on the latter, on the former it most definitely has delivered. Internal emails at JetBrains have been significantly reduced. At least in my case. But I personally feel that it's come at a cost; that of productivity. As a remote person, I very much advocated and encouraged the use of Slack at JetBrains, and I believe that it has greatly benefited our company. In fact, most of our team is remote and we have a channel on Slack which is esssentially the same as a watercooler; giving us a sense of working together and constantly being in touch. Much the same way, it has contributed positively to non-remote workers too. But Slack has also given us the feeling that we can reach out to anyone at any time for anything. The consequence of this however is that frequent interruptions can often lead to context switches which in turn, much like with threads, can impact performance. Now of course, many may say - don't blame the tool but how you use it. And that's OK. In fact many times I've used the same argument, and this post isn't about me "rage-quiting Slack". Instead it's about changing the way I'm now using Slack. A simple rule This change is reduced to a very simple rule: Unless it is urgent, I do not ping a person or a group of people (understanding by this a group DM or small private channel) directly. Instead use email or issue tracker I've moved(ing) back to making use of the right tool at the right moment, as opposed to believing Slack should be used for everything, i.e.: Email or issue tracker for non-urgent discussions or issues that need attention. At JetBrains we make heavy use of YouTrack, not just as a software project management tool, but for many things including organising shows, trips, payments, etc. We also at times use it to have discussions and make decisions. The benefits over email are ## Chasing missing SIGINT signals - SSH DevFeed: [Chasing missing SIGINT signals - SSH]() Original publisher: [Read original article]() Author: info@goteleport.com (Russell Jones) Published: 2018-05-24T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [ssh](), [bug](), [Terminal](), [Command-line interface](), [issue tracker](), [Protocol (disambiguation)](), [Bash]() Tags: [bash](), [bugs](), [cli](), [issue](), [protocol](), [ssh](), [terminal]() ### AI overview This article explains how Teleport investigated a bug in its SSH client that caused Ctrl-C and SIGINT to be mishandled while tailing logs across multiple servers. It compares signal behavior for SSH sessions using a pseudo-terminal with command-execution requests that do not allocate one. ### Source excerpt The first in a series on interesting bugs at Teleport. This post about missing SIGINTs and SSH is useful for Go developers who use signal handling in terminal apps. ## April 2017 Meetup: ExoPlayer 2.0 & Lint - olin DevFeed: [April 2017 Meetup: ExoPlayer 2.0 & Lint - olin]() Original publisher: [Read original article]() Published: 2017-04-25T21:40:44Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [ExoPlayer](), [Android](), [Library](), [issue tracker](), [GitHub](), [App]() Tags: [android](), [app](), [community](), [exoplayer](), [github](), [issue-tracker](), [meetup]() ### AI overview A recap of Touchlab's April 2017 meetup, featuring talks on ExoPlayer 2.0 and Android Lint. The ExoPlayer discussion emphasized understanding its architecture and initialization before customizing it, consulting the official samples carefully, and using the GitHub issue tracker as a learning resource. ### Source excerpt For April, we welcomed Vimeo to our family of awesome meetup hosts! We thoroughly enjoyed their space, swanky arm chairs, and of course, sandwiches & pizza. [Next page]()