That sounds like a really cool idea, I just filed one such bug :)
So, what is the difference between EasyFix and GoodFirstBug?
Should we use both?
Below some additional points.
Thanks,
y
The initial entry point for some people is WebKit github mirror.
Would it make sense to express a few contribution information there?
Something like:
- Contributors are most welcome :) List of good first bugs can be found at
XXX. Expected review time for those bugs should be fairly quick (1 or 2
days?)
- Contribution system is bugzilla, pull requests not accepted through github
- Build instructions can be found at XXX for Mac, YYY for Linux and ZZZ for
Windows
As a newcomer, it is difficult to know whether a patch review should be
expected by the day, the week or the month. Knowing that is useful to react
properly.
In my experience, it is also not only about quickly reviewing newcomers
patches but also about the harder task of being responsive to initial
comments they may make on new/existing bugs.Having such responses may
convince them to actually write their first patches.
The tools used to prepare patches are handy but still require some practice
and may be frustrating, like ChangeLog generation for instance.
I wonder whether it is worth/difficult to translate a github pull
request/github issue as a new bugzilla entry w/o patch. That may be handy
for newcomers as well.
Le lun. 14 déc. 2015 à 18:53, Brian Burg <bb...@apple.com> a écrit :
> Hello WebKittens,
>
> At the WebKit contributors meeting, we held a session to brainstorm ways
> to increase the size of the WebKit community.
> (You can see our notes on the wiki:
> http://trac.webkit.org/wiki/November%202015%20Meeting)
>
> One thing that we really liked about some other projects, particularly
> Mozilla projects such as Servo, Rust, and Firefox,
> is that there are bugs explicitly marked as being “Easy” or a “Good First
> Bug” in Bugzilla. I think we should try this.
>
> Here are some reasons why this works well (and what we should try to
> emulate):
>
> - *Bugs are flagged by experienced contributors who are familiar with the
> feature or component in question*. Identifying
> a good place to start is a big deal: in practice, most Bugzilla instances
> are chockfull of stale, misleading, or outright wrong
> bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if
> components and bugs were always current, there
> are simply thousands of real, actionable tasks which are hard for new
> contributors to judge without domain expertise.
> In WebKit’s Bugzilla instance, we are going to use the *GoodFirstBug and
> EasyFix keywords* to track such bugs.
>
> Once some mentored bugs exist, we may want to think about setting up a
> gateway like Bugs Ahoy! to make searching easier.
>
> - *Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor”*
> who can help a new contributor get up to speed.
> There is a lot of process to be learned to fix even a trivial bug: getting
> the code, building, making changes, writing tests,
> creating and uploading a patch, going through review, and getting changes
> in the tree. In my experience, new folks are happy
> to read and write code, but are easily discouraged from finishing a patch
> because of these barriers. A mentor helps coach
> and encourage a new contributor through these parts of the process. Some
> Bugzilla instances have a field for this; for
> now*, *just* ensure a mentor (you or someone else) is CC’d and responsive
> to questions from the contributor on Bugzilla.*
>
> - *A potential fix for a good first bug should be straightforward,
> described in Bugzilla, and be covered by new or existing tests.*
> This allows a new contributor to achieve a development feedback loop as to
> whether their changes have correct behavior without
> requiring extra effort on the part of mentors. It also educates and
> instills good habits, like writing tests alongside (or even before!) making
> changes.
>
> - *Patches from new contributors are reviewed quickly and regularly.*
> Getting quick feedback is essential to retaining interest
> and momentum, especially for contributors without an economic motivation
> (i.e, a job) or long-term history with the project.
> Feedback should be actionable and constructive. It’s much better to mark a
> patch as review- unless it’s ready to land, than to
> let a patch linger with open questions and the review? flag set. This
> discourages new contributors since the next step is unclear.
>
> Remember, good first bugs serve primarily as an introduction to the
> process of contributing code changes, so they may not
> be particularly interesting to an experienced contributor. Ramping up new
> contributors takes time and effort, but it’s worth it.
>
>
> Have any questions? Feel free to respond, find us on #webkit IRC, or
> contact myself or Jon Davis.
>
> -Brian
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
