expand contributors guideline on README #650

New Issue

GiteaMirror · 2025-11-02T03:31:34-06:00

GiteaMirror commented

2025-11-02 03:31:34 -06:00

Originally created by @mohae on GitHub (Apr 18, 2017).

This is a result of talking with @strk on #go-nuts and the result of a pull request I saw that had no tests associated with it.

I think the contributors section should be expanded to include:

use gofmt
use govet
add test cases that show that the code does what it is supposed to do and handles failures properly, where appriopriate.

There may be additional things, like use golint, make sure errors are not ignored, etc.

I just wanted to start the ball rolling by opening this issue so that there can be additional discussion with the goal of reaching a consensus as to what the Contributors section should include.

Also, should there be more information to help people new to Go, Github, or contributing to Open Source to make it easier for them to get going with regards to contributing to gitea?

Once a consensus is reached, I'd be happy to make a pull request with changes that are consistent with what has been agreed to.

Regards,

Joel

Originally created by @mohae on GitHub (Apr 18, 2017). This is a result of talking with @strk on #go-nuts and the result of a pull request I saw that had no tests associated with it. I think the contributors section should be expanded to include: * use `gofmt` * use `govet` * add test cases that show that the code does what it is supposed to do and handles failures properly, where appriopriate. There may be additional things, like use `golint`, make sure errors are not ignored, etc. I just wanted to start the ball rolling by opening this issue so that there can be additional discussion with the goal of reaching a consensus as to what the **Contributors** section should include. Also, should there be more information to help people new to Go, Github, or contributing to Open Source to make it easier for them to get going with regards to contributing to gitea? Once a consensus is reached, I'd be happy to make a pull request with changes that are consistent with what has been agreed to. Regards, Joel

GiteaMirror added the type/proposal label 2025-11-02 03:31:34 -06:00

GiteaMirror closed this issue

2025-11-02 03:31:34 -06:00

GiteaMirror commented

2025-11-02 03:31:35 -06:00

@strk commented on GitHub (Apr 18, 2017):

For gofmt I filed #1366 some time ago, which would make the Drone build service fail if gofmt wasn't run. Unfortunately it turned out that gofmt can behave differently based on the architecture it is run on.

The vet and lint steps are already checked by Drone (see .drone.yml).

@strk commented on GitHub (Apr 18, 2017): For `gofmt` I filed #1366 some time ago, which would make the `Drone` build service fail if `gofmt` wasn't run. Unfortunately it turned out that `gofmt` can behave differently based on the architecture it is run on. The `vet` and `lint` steps are already checked by Drone (see `.drone.yml`).

GiteaMirror commented

2025-11-02 03:31:35 -06:00

@mohae commented on GitHub (Apr 18, 2017):

For the gofmt, govet, and golint suggestions, it's more so that new contributers know to use those tools, and hopefully encourage them to use them; also so that there's some documentation piece to point back to.

My main concern is tests and being able to consistently have tests be part of the pull request, esp. on bug fixes. The fix should be provable, imo.

@mohae commented on GitHub (Apr 18, 2017): For the gofmt, govet, and golint suggestions, it's more so that new contributers know to use those tools, and hopefully encourage them to use them; also so that there's some documentation piece to point back to. My main concern is tests and being able to consistently have tests be part of the pull request, esp. on bug fixes. The fix should be provable, imo.

GiteaMirror commented

2025-11-02 03:31:35 -06:00

@strk commented on GitHub (Apr 18, 2017):

Personally I agree about requiring tests to be part of pull request, but it would be much easier if we could have an automatic way to check that, can you think about one ?

I also agree about explicitly mentioning the vet, fmt and lint steps in the CONTRIBUTING.md file, mentioning the existance and names of the corresponding Makefile rules. How about sending a PR with those, as a first step ? Then we can discuss the tests enforcement in a separate more specific issue maybe ?

@strk commented on GitHub (Apr 18, 2017): Personally I agree about requiring tests to be part of pull request, but it would be much easier if we could have an automatic way to check that, can you think about one ? I also agree about explicitly mentioning the vet, fmt and lint steps in the CONTRIBUTING.md file, mentioning the existance and names of the corresponding Makefile rules. How about sending a PR with those, as a first step ? Then we can discuss the tests enforcement in a separate more specific issue maybe ?

GiteaMirror commented

2025-11-02 03:31:35 -06:00

@lunny commented on GitHub (Apr 19, 2017):

I also agree with document them what we have implemented in make.

@lunny commented on GitHub (Apr 19, 2017): I also agree with document them what we have implemented in `make`.

GiteaMirror commented

2025-11-02 03:31:36 -06:00

@sapk commented on GitHub (Jan 16, 2020):

All theses commands/tests are in drone and it is explained how to run them locally.
https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#testing-redux

Feel free to re-open if need.

@sapk commented on GitHub (Jan 16, 2020): All theses commands/tests are in drone and it is explained how to run them locally. https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#testing-redux Feel free to re-open if need.

GiteaMirror referenced this issue

2025-11-02 11:48:18 -06:00

[PR #650] [MERGED] Bug fixes for webhook API #15513

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#650