Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update contributing.md #3613

Merged
merged 3 commits into from
Nov 15, 2019
Merged

Conversation

freimair
Copy link
Contributor

  • no "optional" commit signing from now on
  • added PR timeout information

@freimair freimair requested a review from ripcurlx as a code owner November 15, 2019 10:33
@erciccione
Copy link
Contributor

no "optional" commit signing from now on

Why? That sounds like a pointless additional barrier for newcomers.

Copy link
Contributor

@ripcurlx ripcurlx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

@ripcurlx
Copy link
Contributor

no "optional" commit signing from now on

Why? That sounds like a pointless additional barrier for newcomers.

I don't think it is this much effort to sign your commits, but it helps maintainers to know if they can at least rule out the stolen identity case. Until now we only had it as a suggestion for frequent contributors. As it is not possible to set it that granular this helps us as a first alert sign on a PR and doesn't require additional manual checks by maintainers.

@ripcurlx ripcurlx merged commit b536db3 into bisq-network:master Nov 15, 2019
@freimair freimair deleted the update_contributing branch November 15, 2019 13:50
@erciccione
Copy link
Contributor

I don't think it is this much effort to sign your commits,

It is if you are a new contributor who doesn't even have a gpg key to sign with in the first place. You are just assuming everybody does. I really don't see the point in adding a barrier for new contributors, especially since a good amount of devs who make known their intention to contribute, disappear right after.

But at least i'm happy this change was discussed deeply before merging it, after i rised my concern... /s

A PR who changes the workflow for all contributors was opened and merged within 3 hours. A concern was rised, a quick answer was given and then you went ahead merging without even waiting for a reply. You guys have a weird idea of what "decentralization" is.

@ripcurlx
Copy link
Contributor

It is if you are a new contributor who doesn't even have a gpg key to sign with in the first place. You are just assuming everybody does. I really don't see the point in adding a barrier for new contributors, especially since a good amount of devs who make known their intention to contribute, disappear right after.

Would it hold you off to contribute if you want to?

@freimair
Copy link
Contributor Author

A PR who changes the workflow for all contributors was opened and merged within 3 hours. A concern was rised, a quick answer was given and then you went ahead merging without even waiting for a reply. You guys have a weird idea of what "decentralization" is.

The requirement of signed commits has been in force for quite some time now. Just adapting the documentation.

Would it hold you off to contribute if you want to?

I see it the other way: If configuring PGP is too much for a dev, then I am not sure if we want that dev working on our project in the first place.

@erciccione
Copy link
Contributor

erciccione commented Nov 15, 2019

@ripcurlx

Would it hold you off to contribute if you want to?

Why is that a question for me? I already sign all my commits. I didn't rise the issue for myself, it's necessary to have a bigger picture when making workflow changes that effect everybody.

@freimair

The requirement of signed commits has been in force for quite some time now. Just adapting the documentation.

It doesn't really matter if it was in force or not. When you make it official it's the important (since, theoretically, that's the moment you can start enforcing a new workflow)

If configuring PGP is too much for a dev, then I am not sure if we want that dev working on our project in the first place.

Are you serious? So if i am a noob developer who just want to contribute to Bisq and can only do it by fixing typos, i cannot because i don't know how to sign commits? So much for an open and inclusive community.

What personally put me off from contributing is stuff like the statement quoted above, which is against my idea of open source development, and the way the Bisq project is managed by some of the older contributors. Merging pull requests after few hours with no discussion (yes, this is the usual for this repo and others in the Bisq Ecosystem) is part of the problem.

@ripcurlx
Copy link
Contributor

Why is that a question for me? I already sign all my commits. I didn't raise the issue for myself, it's necessary to have a bigger picture when making workflow changes that effect everybody.

I asked you this question just to point out that being able to sign your commits based on the very good documentation by GitHub is not that complicated. Also if you just want to fix typos with the benefit I mentioned above.
Do you have the feeling this change of workflow needs discussion by the broader developer community or did you mainly want to point out PRs in the Bisq repo are merged too quickly in general?

That PRs are merged in different speeds has something to do by whom they are submitted. Is it by a long time contributor and it gets the required ACKs then it can be merged quite quickly as well. Also it depends if it is a simple UI change or something more critical. I don't have the feeling so far that on PRs that were around for longer more contributors are starting to review them, did you? We do have more the problem atm that PRs are open for too long as the load on maintainers to review is quite high.

@erciccione
Copy link
Contributor

I don't have the feeling so far that on PRs that were around for longer more contributors are starting to review them, did you?

That's absolutely not the point. The fact that people don't do it shouldn't exclude the fact that they should have the possibility to do it, but it's clear that Bisq maintainers don't see it that way.

Do you have the feeling this change of workflow needs discussion by the broader developer community

I think would be a start to just not ignore a comment (i consider "ignoring" answering and then merging anyway at the same time, in a timeframe of few hours), if rised.

or did you mainly want to point out PRs in the Bisq repo are merged too quickly in general?

Also, yes. Bisq seems to have workflows more suited for a company than an open source project and this discussion makes it very clear to me.

We do have more the problem atm

"We have other problems" and "there is more important stuff" is the answer i get every time i rise a concern about Bisq's development structure. Very depressing.

@chimp1984
Copy link
Contributor

Are you serious? So if i am a noob developer who just want to contribute to Bisq and can only do it by fixing typos, i cannot because i don't know how to sign commits? So much for an open and inclusive community.

Bisq is a financial project and there are certain risks involved. Signing commits is a small help to reduce that risk. Bisq is not the right place for contributors who are not able to setup PGP. Fixing a small typo is nice to have but it is not what a typical Bisq contribution is about. Anyone could post that and another contributor picks that up as well if signing is too much of a problem.

What personally put me off from contributing is stuff like the statement quoted above, which is against my idea of open source development, and the way the Bisq project is managed by some of the older contributors. Merging pull requests after few hours with no discussion (yes, this is the usual for this repo and others in the Bisq Ecosystem) is part of the problem.

Meritocracy is a key element in Bisq. New contributors like @julianknutsen who start with high quality PRs will automatically gets more attention and in the process get faster merged than others who make many mistakes, do not following the rules or who's PRs have many problems. Maintainers can (like anyone else) decide by themself on what they want to spend their precious time.

@chimp1984
Copy link
Contributor

"We have other problems" and "there is more important stuff" is the answer i get every time i rise a concern about Bisq's development structure. Very depressing.

I think your attitude is not helpful here. Adding more contributors by weakening security should be a no-brainer to anyone familiar with cryptocurrencies. Wasting time to such pointless discussions is one of the problems. Not unique to Bisq.... Trolling is a common problem of open platforms.

@freimair freimair restored the update_contributing branch December 6, 2019 19:39
@freimair freimair deleted the update_contributing branch December 6, 2019 19:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants