We should have a separate roundcube.net specific email.

Which one?

security@roundcube.net is for security issues, not for social issues, in my eyes.

sorry, I made mistake in the comment, I meant "we should create such an address" (could be an alias).

Who would take care of that address, then?

Nextcloud has dedicated people that care about these issues, and having people deal with these kind of issues that are not part of the acting development team is a big plus in my eyes, because developers dealing with complaints might easily get into a conflict of interests.

I suggest we create conduct@... for roundcube, so it is clearly separated in the namespace/domain while I would simply create the alias and point it to the same mailbox. Nextcloud (us/we - since I am an employee of the company, to be transparent here) employed people who take care of such reports in case there are any, this doesn't need to cause work for any developer / contributor.

This file is redundant, I would not include it.

I don't think it is. The chat channel isn't mentioned anywhere else. Also the guideline to not push directly into mutual branches isn't.

I don't think we should link to the nextcloud chat. If you want to introduce a new channel then add it to https://roundcube.net/support/.

Also, you don't want to prevent me from pushing to master, do you?

I don't think we should link to the nextcloud chat

Why not?

That channel is meant for people taking part in the development of Roundcube(mail), not for support topics, thus I don't think roundcube.net/support is the right place.

you don't want to prevent me from pushing to master, do you?

This is not about you and me, it's about the good practice in cooperative teams to not push directly into the main branch – which means: Yes, you shouldn't push into the "master" branch.

Hi @alecpl,
For transparency with each other it's a very good idea to push changes via pull request. This allows others to follow what is happening, and gives room for feedback. Thanks to the CI workflows it will also allow you to see failing CI before an integration into the main branch, so this is also a step towards more stability.

I'd have no strong opinion on this "file", for me the bullet list seems helpful, can be an md file in the repo or a wiki page in the repo but I can understand why this is helpful to people.

As for the impact of

Use (your own) pull requests. Don't push to other people's or mutually used branches. You might break something, or create unexpected code conflicts for others. Pull requests can be opened targeting other people's branches, too.

and your comment on it @alecpl

you don't want to prevent me from pushing to master, do you?

The very short answer would be: "yes" While to me it not about taking it away from you but rather you (as well as @pabzm) giving up this "privilege". Fingers crossed the number of contributors is growing in the future the larger the number on contributors the more painful not working with branches and PRs it will get. If I am correct you still have the administrative power to merge any PR even your own, no? Yet it would be a good first step. (A hack in all transparency would still be to use a single branch of every PR, but I am not suggesting that. Branches or rather PRs simply come with the benefit of documenting the set of change a person is doing that is the some of a certain feature or fix or else one tries to accomplish).

Can't tell if this help with understanding the motivation behind not committing to master directly. Happy to discuss and understand the reasoning behind not wanting to work with branches/PRs in a multi-contributor environment. Whatever the reasons may be (looking forward to reading them), I am sure we can find a solution for that not having to sacrifice a PR-approach.

Looking forward to your comment.

I don't mind creating a PR here and there when a feature/bugfix needs feedback. There are already some PRs I created, but in most cases it's a burden for me.

@alecpl could you please elaborate on the burden? If it's about leaving the terminal/IDE you could give https://cli.github.com/manual/gh_pr_create a try.

I'd be very much interested in the burdens as well. Not having meant my former comment as criticism. Doing everything via PR hasn't been in place until now so any way it has been done is fine. Yet I think it is good to move over to this approach since beyond the need for feedback or discussions a PR is also a very explicit way to "document" sets of changes. My personal short cut is typically to locally work on master, push to a remote branch, have a PR, run GH action on it and then merge on minor changes where no feedback is needed. But it gives others a nice list of changesets, GH notifications about a PR created/merged and some green CI checks ensuring it is really fine to have it on master.

So I understand the burden part while at least in my workflow when I push to a branch local-master to remote-branch I instantly get the link offered to create the PR, so for me is is basically 2 clicks and I am done. So if there is anything that comes to mind to lower the effort of creating and merging PRs, I'd also be interested very much in it.

So to me having a PR is often times than also more about the community of contributors than the creator of the PR.