Michael Gattozzi <mgattozzi@gmail.com> writes:

Hey Michael,

I sent the other e-mails to my inbox, let's see if setting the headers
on this email works to make them slot into the thread on my ML x)

> git has all the capabilities to pull in commits as if they were in
> your own copy as long as there's a public copy to pull from. Just git
> fetch and you have it. The failure mode is when someone doesn't have a
> public copy people can pull from. In this case emailing a patch seems
> like a next best step (and something I've had to do before).

I think this feature is called "request pull", and is what the
pull-request on github is based on.  Indeed, especially for big changes
and projects, it is a good strategy.  I've personally never done one,
but I know of people who have and the semantics of how it works are
quite nice.

The one downside of this is that it requires a platform to host code on
and I think this is where a lot of people are going to be driven to
central hubs, just because the thought is gonna be "how can my work have
the most exposure".

This is what makes a lot of people stick their stuff on GitHub, because
it's that one popular platform that everyone is on. Even if a project
actively makes the choice not to be on GitHub, lot's of peopel still
will be.  That's why I think it's important to make it super easy to
contribute to stuff without having a code copy anywhere.

> I like a lot of what you have written down. I want people to be able
> to do distributed review somehow and email isn't the worst way, it's
> just difficult currently!

I think a lot of it comes down to people not knowing email etticette, or
how to reply in a way that's plain text, and easy to stick comments into
a code block.  At least I find this very natural, but I accept that if
it's not a way that you're familiar with, it can seem offputting maybe.
Not entirely sure what to do about that though.

> I really liked what you laid out and would love to help come up with
> some way we could make email and git better.  I feel like that there's
> a lot to learn here that I just plain don't know or understand and
> working on this kind of tooling would be great.

I think the way that I would want to start with this is to look at
better understanding how to parse an email thread, and rendering patches
that were submitted somewhere in a nice way.  Anything past that is then
down to experimentation on what feels good.

> GitHub came about because the mailing lists and patches sent on old
> projects was tough. I think we can make that experience, not only
> better, but as easy to use as GitHub.

I think one of the things we need to do make people embrace (and embrace
ourselves) is breaking gameification.  I think people talk about it in
the sense of "motivating people", but they don't see the abusive aspects
of it, i.e. being driven to work more and more to make a number go up,
or to make a chart all green.  I think we need to create a culture in
which helping out is something people do because they want to, not
because they feel compelled to because they want to maximise their paper
clips.

This is gonna be weird for people, but maybe with the right social
communication, and tooling, we can make this happen.  I think the mental
health of lots of people would benefit from this.

> If that all makes sense I feel like I was a bit rambly here in the
> email. Needless to say: Email good, current interface with git awful
> and I think we can make it better somehow.

No, it made perfect sense!  Also, a lot of this stuff is new domain in
regards to exploring ways of doing UX, I think we have to explore quite
a few different ideas.

Maybe I'll get a chance to hack together a little program that looks at
a patchset and renders it nicely in a TUI in Rust this week.  I would
send this to you (maybe via a request pull :P), and then we can see
where we can go from there.

Best,
Katharina

Hey Katharina,

I’ll just reply to your comments here:

> This is what makes a lot of people stick their stuff on GitHub, because
> it's that one popular platform that everyone is on.

Yeah this is true. I think as a first stop I’d like to give people the option to leave and
migrate by unbundling it’s value add when it comes to dev-suite at least. Making
self hosting easy is another thing I want to accomplish so that the request-pull
model is successful. It’s super super nice to work with, maintains history etc.

That being said I do agree with your point here:

> That's why I think it's important to make it super easy to contribute to stuff
> without having a code copy anywhere.

What I would love to enable is both! You get to choose a method of contribution
and the experience as a contributor is the same, whether by email or pulling from
a public instance.

 I think the way that I would want to start with this is to look at
> better understanding how to parse an email thread, and rendering patches
> that were submitted somewhere in a nice way. Anything past that is then
> down to experimentation on what feels good.
>
I think this would be a good start. Just being able to pretty print an email thread with
collapsible patches would be a huge improvement, heck if it could be done how
Reddit renders threads and replies would also be useful since things can get out of
order which is kind of the point in some ways.

> I think one of the things we need to do make people embrace (and embrace
> ourselves) is breaking gameification. I think people talk about it in
> the sense of "motivating people", but they don't see the abusive aspects
> of it, i.e. being driven to work more and more to make a number go up,
> or to make a chart all green. I think we need to create a culture in
> which helping out is something people do because they want to, not
> because they feel compelled to because they want to maximise their paper
> clips.
>
> This is gonna be weird for people, but maybe with the right social
> communication, and tooling, we can make this happen. I think the mental
> health of lots of people would benefit from this.

I completely agree with this. Dealing with notifications on GitHub makes me feel
real guilty and not great, but with making it a read only mirror of the actual code
for dev-suite I feel so much better and want to continue working on it.

When it comes to wanting to do it I think about a quote Ursala K. LeGuin’s book
The Dispossessed, "Here you think that the incentive to work is finances, need
for money or desire for profit, but where there’s no money the real motives are
clearer, maybe. People like to do things. They like to do them well.”

I think it’s possible, but in order to do that you need to break the incentives
that centralized services like GitHub bring outside it’s “Gameification”:


• Integrated CI/CD w/ GitHub Actions
• Ticketing system
• Pull Requests and forking
• Tons of apps that can hook into your pipeline

They’re not easy incentives to break, but if we can provide easier human
friendly interfaces with dead simple configuration/UX so that anyone can get
started, newbie and veteran alike, then I think it’ll be easier to overcome.
It’s not just if your software is good, it’s also if it’s easy to use and pretty.

I think we can do that and I have my own stake in this because of my mental
health issues and if we can help others then that will be great.

> Maybe I'll get a chance to hack together a little program that looks at
> send this to you (maybe via a request pull :P), and then we can see
> where we can go from there.

Oh that sounds great! I’ll need to familiarize myself with email more this week
as well! :D

Best,
Michael Gattozzi

On Mon, Jan 06, 2020 at 05:05:40PM +0000, Katharina Fey wrote:
> Michael Gattozzi <mgattozzi@gmail.com> writes:
> 
> Hey Michael,
> 
> I sent the other e-mails to my inbox, let's see if setting the headers
> on this email works to make them slot into the thread on my ML x)
> 
> > git has all the capabilities to pull in commits as if they were in
> > your own copy as long as there's a public copy to pull from. Just git
> > fetch and you have it. The failure mode is when someone doesn't have a
> > public copy people can pull from. In this case emailing a patch seems
> > like a next best step (and something I've had to do before).
> 
> I think this feature is called "request pull", and is what the
> pull-request on github is based on.  Indeed, especially for big changes
> and projects, it is a good strategy.  I've personally never done one,
> but I know of people who have and the semantics of how it works are
> quite nice.
> 
> The one downside of this is that it requires a platform to host code on
> and I think this is where a lot of people are going to be driven to
> central hubs, just because the thought is gonna be "how can my work have
> the most exposure".
> 
> This is what makes a lot of people stick their stuff on GitHub, because
> it's that one popular platform that everyone is on. Even if a project
> actively makes the choice not to be on GitHub, lot's of peopel still
> will be.  That's why I think it's important to make it super easy to
> contribute to stuff without having a code copy anywhere.
> 
> > I like a lot of what you have written down. I want people to be able
> > to do distributed review somehow and email isn't the worst way, it's
> > just difficult currently!
> 
> I think a lot of it comes down to people not knowing email etticette, or
> how to reply in a way that's plain text, and easy to stick comments into
> a code block.  At least I find this very natural, but I accept that if
> it's not a way that you're familiar with, it can seem offputting maybe.
> Not entirely sure what to do about that though.
> 
> > I really liked what you laid out and would love to help come up with
> > some way we could make email and git better.  I feel like that there's
> > a lot to learn here that I just plain don't know or understand and
> > working on this kind of tooling would be great.
> 
> I think the way that I would want to start with this is to look at
> better understanding how to parse an email thread, and rendering patches
> that were submitted somewhere in a nice way.  Anything past that is then
> down to experimentation on what feels good.
> 
> > GitHub came about because the mailing lists and patches sent on old
> > projects was tough. I think we can make that experience, not only
> > better, but as easy to use as GitHub.
> 
> I think one of the things we need to do make people embrace (and embrace
> ourselves) is breaking gameification.  I think people talk about it in
> the sense of "motivating people", but they don't see the abusive aspects
> of it, i.e. being driven to work more and more to make a number go up,
> or to make a chart all green.  I think we need to create a culture in
> which helping out is something people do because they want to, not
> because they feel compelled to because they want to maximise their paper
> clips.
> 
> This is gonna be weird for people, but maybe with the right social
> communication, and tooling, we can make this happen.  I think the mental
> health of lots of people would benefit from this.
> 
> > If that all makes sense I feel like I was a bit rambly here in the
> > email. Needless to say: Email good, current interface with git awful
> > and I think we can make it better somehow.
> 
> No, it made perfect sense!  Also, a lot of this stuff is new domain in
> regards to exploring ways of doing UX, I think we have to explore quite
> a few different ideas.
> 
> Maybe I'll get a chance to hack together a little program that looks at
> a patchset and renders it nicely in a TUI in Rust this week.  I would
> send this to you (maybe via a request pull :P), and then we can see
> where we can go from there.
> 
> Best,
> Katharina