]> git.openstreetmap.org Git - rails.git/commitdiff
Merge remote-tracking branch 'upstream/pull/5319'
authorTom Hughes <tom@compton.nu>
Wed, 13 Nov 2024 18:40:02 +0000 (18:40 +0000)
committerTom Hughes <tom@compton.nu>
Wed, 13 Nov 2024 18:40:02 +0000 (18:40 +0000)
1  2 
CONTRIBUTING.md
FAQ.md

diff --combined CONTRIBUTING.md
index a6456bec11ca86b9c3ab4bee74cd1d5309ae89de,539aaa5cf7960559a4ed7234abe1a9d39b7ae363..e298c944f5819d2b72d8bf14cfb34e6a692de7a1
@@@ -1,13 -1,8 +1,15 @@@
+ # Contributing
  * https://www.ruby-lang.org/ - The homepage of Ruby which has more links and some great tutorials.
  * https://rubyonrails.org/ - The homepage of Rails, also has links and tutorials.
  
 +## Assigning Issues
 +
 +We don't assign issues to individual contributors. You are welcome to work on any
 +issue, and there's no need to ask first.
 +
 +For more details see [our FAQ](FAQ.md)]
 +
  ## Coding style
  
  We use [Rubocop](https://github.com/rubocop-hq/rubocop) (for ruby files)
diff --combined FAQ.md
index da473a6b4d8302a171a11f6d5146d2b7da103a5e,4ab043338a137a9ebafaae2efccbe4f9e0489f60..e53c8dddb4195288797355a975395b41dcaa7ac5
--- 1/FAQ.md
--- 2/FAQ.md
+++ b/FAQ.md
@@@ -1,3 -1,5 +1,5 @@@
+ # Frequently Asked Questions
  ## How do I create a banner to promote my OpenStreetMap event?
  
  We occasionally display banner images on the main page of [openstreetmap.org](https://www.openstreetmap.org/) to
@@@ -23,13 -25,3 +25,13 @@@ drive.  This is a great way to reach a 
  
  See [PR #1296](https://github.com/openstreetmap/openstreetmap-website/pull/1296)
  as an example.
 +
 +## Why don't you assign issues?
 +
 +We don't assign issues to volunteers for several reasons. The main reasons are that it discourages other volunteers from working on the issue, and the process turns into an unproductive administrative overhead for our team.
 +
 +There's no need to ask for an issue to be assigned before anyone starts working on it. Everyone is welcome to work on any issue at any time.
 +
 +In our experience, most people who ask for an issue to be assigned to them never create a pull request. So we would need to keep track of the assigned issues, and remember to unassign them a week or two into the future, when it is likely that they will not be making a PR. Assigned developers might feel bad if they perceive that we're unhappy with their progress, further discouraging them from contributing. Or we will get drawn into discussions about needing more time, or re-assigning them again, or so on. So it is best not to assign in the first place.
 +
 +The risk that two people are both genuinely working on the same task in the same hour or two is vanishingly remote, and doesn't outweigh the downsides described above. A better approach is to encourage people to simply work on the task and create a pull request, at which point everyone knows that they are actually working on the issue and not just planning/hoping/wishing to do so.