5 ms·

I do not understand why the issue is not discussing DeVault's straightforward robots.txt suggestion: > Have you considered the robots.txt approach, which would

I do not understand why the issue is not discussing DeVault's straightforward robots.txt suggestion: > Have you considered the robots.txt approach, which would simply allow the sysadmin to tune the rate at which you will scrape their service? The best option puts the controls in the hands of the sysadmins you're affecting. This is what the rest of the internet does. The only explanation I see later in the thread is: > For boring technical reasons, it would be a fair bit of extra work for us to read robots.txt, so rather than going to a bunch of work to do that, we implemented a trivial list and offered to add sr.ht to it. This is...not a satisfactory technical explanation. Perhaps the Go team should consider providing more openness and transparency about why it's "a fair bit of extra work" to implement an internet standard like DeVault suggests. Honestly, DeVault is an abrasive person and not necessarily someone I would go out of my way to work with, but I don't see how the Golang team isn't at least somewhat at fault here for brushing off a community member with "Eh, it's too complicated for you to understand". That's not how you build a thriving community around a language.

tptacek 4y ago
They didn't brush him off. They gave him an immediate workaround, which --- contra some messages on this thread --- did not entail making sr.ht unusable for Go projects. At the time he posted this, he had not taken the Go team up on that workaround; doing so appears to involve only DeVault saying "go ahead" to the Go team.
- quadrifoliate 4y ago
  > They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tracker in violation of their own CoC does not seem like good faith behavior either. Note that the message from 'FiloSottile does not clearly spell out whether DeVault's ban was following a CoC, it just obliquely quotes some nasty stuff that he's apparently said in the past. I think other commenters are correct to call it irrelevant, it's about as relevant as it would be if I started randomly quoting Rob Pike's notorious comments about syntax highlighting [1]. Overall, I totally acknowledge the Golang team is providing a workaround that will solve the (admittedly abrasively spoken) user's problems. What I'm saying is that that is not enough. If you want an open language that will not turn into .NET, you have to do better by your community and also be transparent as to how and when you're planning to solve your users' problems. And preferably also be transparent about CoC bans, especially if there is a technical discussion involved. For example, this sounds like a reasonable response to me: "We have written up a task to make our proxy code parse robots.txt correctly, but there are N other tasks above it, and it looks like we won't be able to work on it for approximately the next six months. Until then, a workaround is..." ---------------------------------------- [1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ1RDiio8J https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ....
  - tptacek 4y ago
    This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why. There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this. There's always going to be some standard the Go team (or the Rust team, or the Clojure team, or the Scala team, or any other team down the line until you just decide to do your own language and hope for the day you get to occupy the gratifying job of fielding these kinds of tickets) doesn't meet, for someone on some message board somewhere.
    - deleted 4y ago
      [deleted]
    - voxtech 4y ago
      This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.
      - tptacek 4y ago
        That logic doesn't even cohere. If Github and Gitlab can sustain more aggressive queries from the module proxy, they may have fresher cache entries in that proxy. That's what being more capable gets you. The Go team isn't obligated to operate at the lowest common denominator of all source hosts. If the Go team's workaround was to make sr.ht not viable for Go modules, that would be deeply problematic. But it isn't; in fact, nobody who's upset about this seems to be able to describe what the Go team's workaround would even impact. Can you?

tptacek 4y ago

They didn't brush him off. They gave him an immediate workaround, which --- contra some messages on this thread --- did not entail making sr.ht unusable for Go projects. At the time he posted this, he had not taken the Go team up on that workaround; doing so appears to involve only DeVault saying "go ahead" to the Go team.

quadrifoliate 4y ago
> They didn't brush him off. I disagree, the "for boring technical reasons..." is as close to a brush-off as I can see. This is a technical issue tracker, why not be open and honest about the reasons? I feel like these days people just seem to take it on faith that "Oh, it's Google, surely they know best when they say it's a mysterious technical issue that's too hard to solve". Also, banning someone from the issue tracker in violation of their own CoC does not seem like good faith behavior either. Note that the message from 'FiloSottile does not clearly spell out whether DeVault's ban was following a CoC, it just obliquely quotes some nasty stuff that he's apparently said in the past. I think other commenters are correct to call it irrelevant, it's about as relevant as it would be if I started randomly quoting Rob Pike's notorious comments about syntax highlighting [1]. Overall, I totally acknowledge the Golang team is providing a workaround that will solve the (admittedly abrasively spoken) user's problems. What I'm saying is that that is not enough. If you want an open language that will not turn into .NET, you have to do better by your community and also be transparent as to how and when you're planning to solve your users' problems. And preferably also be transparent about CoC bans, especially if there is a technical discussion involved. For example, this sounds like a reasonable response to me: "We have written up a task to make our proxy code parse robots.txt correctly, but there are N other tasks above it, and it looks like we won't be able to work on it for approximately the next six months. Until then, a workaround is..." ---------------------------------------- [1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ1RDiio8J https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ....
- tptacek 4y ago
  This is how every issue tracker works. It takes time to explain things (and more time to generate all the facts needed to put together an accurate explanation). What matters is that they got him a workaround --- apparently, almost immediately. He hasn't taken them up on it; it's unclear why. There's no indication I can see that DeVault's "banning" from the issue tracker has anything to do with any of this. There's always going to be some standard the Go team (or the Rust team, or the Clojure team, or the Scala team, or any other team down the line until you just decide to do your own language and hope for the day you get to occupy the gratifying job of fielding these kinds of tickets) doesn't meet, for someone on some message board somewhere.
  - deleted 4y ago
    [deleted]
  - voxtech 4y ago
    This claim is outrageous- if disabling sourcehut is a valid workaround, then google should end the refresh behavior on the proxy since it isn't providing any valuable service. If the proxy provides a valuable service, then disabling sourcehut would degrade service for sourcehut users.
    - tptacek 4y ago
      That logic doesn't even cohere. If Github and Gitlab can sustain more aggressive queries from the module proxy, they may have fresher cache entries in that proxy. That's what being more capable gets you. The Go team isn't obligated to operate at the lowest common denominator of all source hosts. If the Go team's workaround was to make sr.ht not viable for Go modules, that would be deeply problematic. But it isn't; in fact, nobody who's upset about this seems to be able to describe what the Go team's workaround would even impact. Can you?