Hi rust-dev,
I thought we should have a brief discussion on the development policy,
specifically about bug assignment (from the perspective of a new
contributor to the Rust codebase).
# Motivation
I had a working patch for fixing a small Rust issue (my first Rust
bug) at one point before some major compiler changes stalled my patch
as I was waiting it out, but I did my best to continue to express my
intent to finish the bug fix. However, another contributor (not core
team but GitHub collaborator privileges) recently decided to submit
their request and bors happily ran off to integrate it.
Of course, working code beats non-pull requested code any day, but I
did leave disappointed nonetheless.
# The Problem
Unfortunately, GitHub does not allow bug assignment to
non-collaborators, but I do not believe I could have been clearer that
I was working on the bug (first comment, referenced the bug in another
issue). For what it's worth, they acknowledged they still did not
realize the bug was taken, so we did a bit of yo-yoing on who exactly
was going to work on it since their code wasn't quite there yet until
the next snapshot either, but we seemed to agree that I would wrap up
the bug AFAICT. Moreover, the bug was a very simple one and not on the
block for 0.7, so that is all the more reason for it to not have been
pressing to work on.
To avoid sounding like I'm crying over spilled milk, I am entirely on
board if someone has code that already works and encourage more
frequent contributions to Rust, but this is all to say I believe the
situation could have been avoided if we could adopt more formal bug
assignment.
tl;dr The current development policy [1] is if a bug is unassigned,
then it is fair game so long as you comment on the bug (for
non-collaborators). From my experience, I feel this system is
insufficient in identifying bug owners.
# Potential Solutions
* Transfer Mozilla to an organization account [2] (may already be the
case) then add the potential bug fixer as a read-only collaborator in
order to gain the ability to officially assign them to the bug
- Downsides: with a busy core team, this could get unwieldy very
quickly to add read-only contributors who may not even finish fixing
their bug
* Stick with commenting on bugs, but do what some projects have adopted:
Assigned to @foouser
so at least foouser can filter issues according to "mentioning you".
- Downsides: this "solution" is the same policy with a bit more
formality and all of the same flaws
# Conclusion
I doubt this is a pervasive issue in the community and it's most
likely my little exposure to OSS development that leaves me a bit
sensitive, especially as I've only contributed some code cleanups to
Firefox so far. However, Bugzilla (and all its faults) at least makes
it clear if someone is working on a bug/issue, and I think it would be
valuable if we adopt a solution that will prevent future contributors
from feeling as if they are in a race to pull request first.
[1]:
https://github.com/mozilla/rust/wiki/Note-development-policy#getting-involved-how-to-pick-your-first-bug
[2]: https://github.com/blog/674-introducing-organizations
Sincerely,
Isaac Aggrey
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
