"Just show me the prompt."

If you don't have time, just write the damn issue as you normally would. I don't quite understand why one would waste so much resources and compute to expand some lazily conceived half-sentence into 10 paragraphs, as if it scores them some points.

If you don't have time to write an issue yourself or carefully proofread whatever LLM makes up for you, whom are you trying to fool by making it look pretty? At least if it is visibly lazy anyone knows to treat it with appropriate grain of salt.

Even if you are one of those who likes to code by having to correct LLMs all the time, surely you understand if your LLM can make candy out of poo when you post an issue then it can do the exact same thing when it processes the issue and makes a PR. Likely next month it will do a better job at parsing your quick writing, and having it immediately "upscaled" would only hinder future performance.

▲

xg15 9 hours ago | parent | next [-]

What would make sense for me is to use an AI to turn implicit context that is only there in the moment into explicit context that is stored in the ticket.

E.g. maybe you have your application open in a browser and are currently viewing a page with a very prominent red button. You hit that /issue command with "button should be yellow not red".

That half-sentence makes sense if you also have that open browser window as context, but would be completely cryptic without.

An AI could use both the input and the browser window to generate a description like "The background color of the #submit_unsafe button widget in frontend/settings/advanced.tsx should be changed from red to yellow." or something.

Sort of like a semantic equivalent to realpath if you want.

I do see utility in that.

▲

nix0n 3 hours ago | parent | next [-]

I think a URL and screenshot would be way more useful than a bunch of text for that use case.

	▲	swores an hour ago \| parent [-]
		But maybe the button only appears on that URL if you've first pressed something else, or if you're logged in/out, or maybe that URL has a different token each day that makes it seem like a completely different URL, or...

▲

skydhash 5 hours ago | parent | prev [-]

> You hit that /issue command with "button should be yellow not red".

Wouldn’t it be easier to just open the inspector, find the css class, grep the source code, and then edit the properties? It could be even easier in an SPA where you just have to find the component file.

▲

bluGill 3 hours ago | parent | next [-]

If you are a web programmer sure. I write embedded code, I know all the things you are talking about in the abstract, but I'm not good at them because none of them have ever been relevant for anything I do. Give me a few hours and I can figure it out (maybe minutes, maybe days? - if you know this area your guess might be better than mine), but it isn't something worth my time.

there are a lot of people who are not programmers at all. I can teach my plumber everything you said (learning it myself is the easy part), but it will take years. In the end they just know "that button I'm pointing my finger at should be yellow not red". How to we transfer that pointed finger to a ticket is the question here.

	▲	skydhash 2 hours ago \| parent [-]
		> How to we transfer that pointed finger to a ticket is the question here. There’s a reason the Support and IT Technician role exists. They’re there for talking to the end user. And they in turn will write a proper report to Engineering. If you want to wear both hats at once, that is fine. If you want an agent to be your support middleman, that is also fine. But most LLM proponents are acting like it’s a miracle solution to some engineering bottleneck.

▲

xg15 4 hours ago | parent | prev [-]

> where you just have to find the component file.

This can be a substantial effort, especially if you're not familiar with the project.

▲

pwdisswordfishs 5 hours ago | parent | prev | next [-]

On the Web, the github.com/*/*/issues namespace is home to the worst bugtracker behavior in the world. A bugtracker should should be restricted to bug reports and (well-informed) proposals and discussion about the bug/bugfix. The bug report should contain, at minimum and at maximum:

1. Clear steps to reproduce (ideally, using the prepared testcase as input, if applicable)

2. A description of the behavior observed from the program

3. A description of the expected behavior

4. Optionally, your justification for why the program should be changed to behave the way described in #3 and not #4

Everything else belongs on a message board, mailing list, or social media.

But this is all totally foreign to, like, 80% of GitHub's userbase (including the majority of the project managers aka maintainers who are in charge of allowing/disallowing the sorts of things that people post as a way of shaping the tone and tenor of the space).

▲

mschuster91 3 hours ago | parent [-]

> Everything else belongs on a message board, mailing list, or social media.

There's a reason that collaborative code platform (not just GH but also GL) "issues" end up being used for much more than bugs:

- message boards suffer from the SSO friction issue. No thanks I will not sign up at some phpBB board of questionable admin quality that will get 0wned sooner than later, or have the board owner bombard me with advertising themselves.

- mailing lists are even worse usability-wise because these by design leak your email address, on top of that their management UI often enough is Mailman which means it probably still stores passwords in cleartext, and spam filters, attachment size limits and overeager virus scanners make it a living hell

- IRC suffers from context loss. Netsplit, go for a smoke and the laptop goes to sleep, whoops, you disconnected and don't see what happened in the meantime. Yes, there's bouncers, but honestly, the UX sucks hard. Also, no file transfers to a channel, no native screenshot/paste functionality.

- Discord, Slack etc. solve the pains of IRC but are walled gardens

- Social media... yikes. No, no, no. Eventually, people that follow both you and the author of some FOSS software get pissed off by your conversation spamming their feed. (Too) many are still only active on Twitter which excludes people who don't want to be on that hellsite. Bluesky, good luck finding non-commies there. Mastodon, good luck and pray that your instance operator and the instance operator of the project team didn't end up in some bxtchfight escalating in defederation. Facebook groups, not everyone wants to leak their real name.

- messenger groups (especially Telegram)... blergh. You will drown in spam.

GH/GL are the sweet spot between UX/SO friction (because pretty much everyone who would want to file an issue has an account) and features, and on top of that both platforms have deals with email providers preventing them from getting blocked. That's why these two platforms are so far superior above everything else mentioned.

	▲	tolerance 3 hours ago \| parent \| next [-]
		What do you think about Discourse in particular.
	▲	simoncion an hour ago \| parent \| prev \| next [-]
		> - mailing lists are even worse usability-wise because these by design leak your email address... So does git and GitHub. Last I checked, authoring a git commit with an email address associated with your GitHub account is what makes GitHub attribute that commit to your account. I assume Gitlab works in a very similar way. "But 'git clone' is soooo much harder than reading through mailing list archives!" Nah.
	▲	Pxtl 3 hours ago \| parent \| prev [-]
		GH has a "Discussions" feature for message-boards attached to your project. Same sign-on as GH. Nobody turns it on.

▲

anal_reactor 2 hours ago | parent | prev | next [-]

> I don't quite understand why one would waste so much resources and compute to expand some lazily conceived half-sentence into 10 paragraphs, as if it scores them some points.

Because it does. The goal here isn't to create good code, it's to create an impression of a person who writes good code. Even now, when software career is in freefall, for many people in poor countries it's still their only way out of poverty so they'll try everything possible to build a portfolio and get a job and the suffering of your little pet project isn't a part of the equation. Those people aren't trying to get Nobel prizes, they're trying to get any job that isn't farming with literal medieval-era technology.

My very radical personal opinion is that either we have small elitist circles of trust, or the internet will remain a global ghetto.

▲

HPsquared 10 hours ago | parent | prev [-]

The context windows before a prompt is often large and contains all sorts of information though, it wouldn't be just a prompt in isolation.

▲

anileated 9 hours ago | parent [-]

I was going by this example:

> /issue you know that paint bucket in google docs i want that for tldraw so that I can copy styles from one shape and paste it to another, if those styles exist in the other shape. i want to like slurp up the styles

What kind of context may be there?

Also, the entire repository and issue tracker is context. Over time it gets only more complete.

	▲	n_e 6 hours ago \| parent \| next [-]
		I don't get it either. The LLM-generated issue from the above prompt is just the same information written more verbosely.
	▲	HPsquared 7 hours ago \| parent \| prev [-]
		The entire chat log up until the user asks it to generate a summary. And maybe "memories" and custom system prompts for good measure. A lot of potentially private information, in other words. "Just the prompt" only works in a very particular case where you ask it for something out of the blue.