Here's an example of a web-based #Git UI being used to make a legitimate contribution by someone who isn't a software engineer, and may not have been able to contribute using the Git CLI:
github.com/lulzlabs/AirChat/pu

@strypey @Wolf480pl @Michcioperz whether or not this is a "legitimate contribution" is _highly_ debatable

@sir @Wolf480pl @Michcioperz *sigh* you can pick on the specifics of the example. My point is that there are things that non-engineers can do that, assuming it's something the engineers would otherwise have had to do themselves, saves the engineers time they can spend on things that require their skills. There are none so blind as those who will not see, I guess ;-)

@sir @Wolf480pl @Michcioperz in case the context wasn't clear, I was picking up on our previous conversation about whether it is useful to engineers to have drive-by contributions, particularly from non-engineers. Engineers and designers developing user-facing software can be aided greatly by having end users file bug reports, and communicate their feature and UI needs. Web-based tools like GH and #GitLab were created to serve those needs. This, specifically, is what needs federating.

@strypey @sir @Wolf480pl @Michcioperz Agreeing with what @sir has said previously, I think Git itself probably has enough federation for this to work.

What is needed is for all of that functionality to be exposed via web-based UIs.

@alcinnz how do you @mention other users across instances with only Git plus a web UI?
@Wolf480pl

@strypey @Wolf480pl eMail's thrown in as well, so maybe use that?

Also it needs to be said Git doesn't build in issue tracking, but I'm happy with that being centralized on the same server publishing the Git repo to the world. As long as all or most issue trackers aren't centralized on the same site.

And as long there's no burden of setting up an account on each of these servers getting in the way of drive by contributors. I appreciate that sr.ht at least gives me that option.

@alcinnz
> eMail's thrown in as well, so maybe use that?

Use that how? With only what's currently built into Git + email protocols. Before giving your answer, please make sure you didn't just start reinventing an existing web protocol like WebMentions or Webfinger.
@Wolf480pl

@strypey @alcinnz
>make sure you didn't just start reinventing an existing protocol

ActivityPub didn't have problems reinventing email, so...

@Wolf480pl oh come on. I seriously doubt that people like Evan, Chris, and Eugen, would have spent years of their lives assembling AP if they could have just used existing protocols. If you think you can build a web-based, federated social network client, using only email protocols, let's see it.
@alcinnz

Follow

@strypey @alcinnz
Well, I'm probably oversimplifying a bit.

But I'm under the impression that these days, everybody looks at new shiny web technologies, and forgets about the good old IETF protocols, which sometimes solve the same or very similar problem in a much more elegant way.

And even if the old protocols not a good solution for a particular problem, there's a lot modern dev could learn from them.

And the arguments like "who still uses $X in 2018" or "it's not 90s anymore" are th worst

@Wolf480pl
> Well, I'm probably oversimplifying a bit.

Maybe a bit, yes. I mean, you can't even do *webmail* with only the email protocols.
@alcinnz

@strypey @Wolf480pl @alcinnz

Yes, this is progress!

~Waste~ Spend decades to do in a #Web browsers what you could do in months with a dedicated software.

Two years ago I was asked to estimate the introduction of a button in our web application that started a remote desktop connection to one of our server running #Excel.
I laughed aloud.

But I've finally realised that the alternatives to achieve this (#JavaScript and #WebAssembly) are way worse.

Sign in to participate in the conversation
niu.moe

Welcome to your niu world ! We are a cute and loving international community O(≧▽≦)O !