Manuel Kaufmann
Manuel Kaufmann
> This is maybe assuming a bit much. Anecdotal, but I don't ever view PR pages when opening a PR. I use `hub`/`gh` cli tools to create issues and PRs....
We should have one and only one comment. Then, on every push, we should update that comment with the latest updates. That's what I'm saying.
> What I was describing was only commenting if a build causes updates to the list of files. Otherwise, the comments wouldn't have build state and the links wouldn't have...
> even if the comment is very minimal, it adds noise to the PR page I agree with @stsewd here
> The build detail link isn't a problem to include. But it's at worst not super useful to users. On builds passing the build detail page isn't very helpful, on...
In my experience multiple automated comments add a lot of noise to the workflow and make it hard to follow the conversation in the PR. Also, I'd prefer to start...
@silentfatez Hi, are you still planning to work on this PR? There is a some review on it that you may want to take on so we can move forward...
> * A sitemap of version URLs (this is the current prod sitemap) > * A sitemap for each version (new) > * A sitemap for each subproject version (new)...
Does it make sense to return different content under `/sitemap.xml` when adding the `?version` argument? Is this something standard for sitemaps?
> And in addition, this replaces the XML and XML comment approach, which > doesn't render in many browsers, with a super basic XSLT template. Is XSLT supported for sitemaps?...