On Wed, Mar 15, 2023 at 12:35:20PM +0100, Peter Dobsan wrote:

> Small things in UX design could matter. The circle of people interacting
> with Sourcehut in one way or in another is much larger than the subset
> of registered users preferring these unusual choices.
> 
> Ironically these things make CLI usage, otherwise rightly cherished by
> most people around here, more difficult. 

Greatly agree. Sourcehut has many unique features whose benefits are obvious
and large, and I'm a fan. It also has some unique features without obvious
benefits, the sort of thing where people end up muttering words like "for
historical reasons...".

On Thu, Jul 28, 2022 at 07:53:32PM +0200, Moritz Poldrack wrote:
> On Thu Jul 28, 2022 at 7:40 PM CEST, Dan Shearer wrote:
> > anyone who has used RT's jumbo ticket screen will be familiar with an
> > extreme example.
> I am not, could you share an example? This sounds interesting.

Standard ticket create: https://rt-wiki.bestpractical.com/wiki/File:Ticket-Create.png

Jumbo screen is where every field is editable, but I can't find a screenshot on the internet atm sorry. Perhaps in the BestPractical wiki in a place I didn't notice.

Dan

Would it be useful to have "add label" and "assign to" on the ticket creation
screen? At present changing these properties required editing the ticket once
created. I do also appreciate the current simplicity, and perhaps that is the
intention.

Most ticketing systems I have used seem to evolve towards exposing lots of
state on the creation screen and I find it useful (anyone who has used RT's
jumbo ticket screen will be familiar with an extreme example.)

Best,

--
Dan Shearer
dan@shearer.org

On Fri, Feb 11, 2022 at 02:03:44PM +0100, Dan Shearer wrote:

> > Integration with proprietary services is explicitly stated as out of
> > scope for SourceHut. You're on your own.
> 
> And not where I want to be, I assure you. Ok, that's a principled approach.
> 
> However, I see that the GitHub cli has been under steady development:
> https://cli.github.com/ .  It seems that "gh pr create" will likely do what I
> want it to do from a Git checkout of an sr.ht tree.

Before anyone gets too excited that there is a way of interacting with GitHub
entirely from the commandline and/or in an automated fashion, no there is not.
There is a partial solution that I can use to build a minimal bridge to one GitHub project.

On Fri, Feb 11, 2022 at 01:51:35PM +0100, Drew DeVault wrote:
> Integration with proprietary services is explicitly stated as out of
> scope for SourceHut. You're on your own.

SourceHut needs to make it a bit more explicit. For example https://man.sr.ht/dispatch.sr.ht/github.md says:

  dispatch.sr.ht supports various integrations with GitHub. Some tips are provided here.

I also tried the search string "site:sr.ht integration proprietary" on several search engines without useful result.

I thoroughly support your view and I think it is an attractive benefit of SourceHut.

--
Dan Shearer

On Fri, Feb 11, 2022 at 01:51:35PM +0100, Drew DeVault wrote:

> Integration with proprietary services is explicitly stated as out of
> scope for SourceHut. You're on your own.

And not where I want to be, I assure you. Ok, that's a principled approach.

However, I see that the GitHub cli has been under steady development:
https://cli.github.com/ .  It seems that "gh pr create" will likely do what I
want it to do from a Git checkout of an sr.ht tree.

Thanks,

--

What is the recommended way to communicate patches to GitHub users in the manner they are used to, ie PRs?

Use case: hosting a project entirely on SourceHut which is forked from and independently run to a project on GitHub.

I suppose the workflow might be something like:

* fork original upstream project A to tree B on $my GitHub account 
* create project C on sr.ht which is a hard fork of A
* push a commit from C to B
* create a job on dispatch.sr.ht that uses the GitHub API to create a GitHub PR from $my GitHub account to A for that commit

I note https://man.sr.ht/dispatch.sr.ht/github.md and https://man.sr.ht/git.sr.ht/#sending-patches-upstream but do not think they address this specific point.

I am not asking how to replicate GitHub workflows on sr.ht, just how to interact with GitHub with the lowest friction possible.

On Tue, Nov 30, 2021 at 09:49:50AM +0100, Drew DeVault wrote:
> On Tue Nov 30, 2021 at 9:48 AM CET, Dan Shearer wrote:
> > sr.ht isn't quite[1] GDPR compliant, because there isn't a link to it
> > on the main page.
> 
> Not true: we don't collect data about you until after you sign up, and
> we put a link to this on the registration page. We are compliant.

Oh I see it, yes you are quite correct. The requirements are only that it be clear,
easily-found, accessible and a few other things as stated in Articles 12, 13 and 14.
This result is not found by a Google search like "link:https://man.sr.ht/privacy.md site:sr.ht"

It is merely a commonly-held opinion that it is a good idea to make the privacy
policy immediately available to everyone who visits, by putting it on the front page.

On Mon, Nov 29, 2021 at 11:42:34PM +0100, Drew DeVault wrote:
> Hi! It's still a priority, but we still have work to do. 

In case anyone is wondering, in the meantime sr.ht remains completely compliant
with the GDPR and the many GDPR-like requirements around the world because of
https://man.sr.ht/privacy.md#how-to-access-and-control-the-information-weve-collected .

sr.ht isn't quite[1] GDPR compliant, because there isn't a link to it on the main page.
I will raise a ticket for this trivial but important bugfix as soon as I am asked, according to:

   "... you must start by posting to sr.ht-discuss if this does not describe your issue. You will be asked to file a ticket if appropriate."


--