This is true for collaborators who are “external developers” for that repository. In this case, @gabriel is a “collaborating developer”—actually, the official maintainer in this case—and he does have write access. So @gabriel, a simpler option than the fork-and-PR model is:
- Clone the repo
- Make the change (on master branch)
- Commit the change
- Push the change (directly to remote master)
It might look something like:
git clone https://github.com/fiji/Auto_Threshold
# make the change
# install new plugin into your Fiji
mvn -Dimagej.app.directory=$HOME/Desktop/Fiji.app -Ddelete.other.versions=true
# run your Fiji to test the change
# push the change
git commit -a -m 'Fix bug in Auto Threshold plugin'
Of course, as @imagejan said, if the change is super simple and can be done directly through the web via the Edit button, that is even simpler.
If the changes are large, you can still make a topic branch and push that, then file a PR. This is useful if you want others to review and discuss the changes before they are merged, and/or if the work is not yet finished.
Once the work is on the
master branch, we still need to cut a new Maven release, and then upload that release to the appropriate ImageJ update site, so that users receive the fix. We try to do this every few weeks, or sooner if plugin maintainers request it.
See the Development Lifecycle page for full details on all of this.