Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80013
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
Date: Tue, 30 Dec 2014 07:15:22 +1000 (AEST)
To: internals@lists.php.net
In-Reply-To: <54A1A04B.1080104@php.net>
Message-ID: <alpine.OSX.2.11.1412300700250.10442@jacobs-macbook-pro.local>
References: <CAJW__o3M+aaEKmc+Q5C-1rK5vu5LtixU797_oA2V8MbHwhf88w@mail.gmail.com> <54A109EB.1000805@gmail.com> <CAFMT4Nq-5eLJ=SvmrN754kRWufukyja+v+V7Hh_5wMNghifCdw@mail.gmail.com> <54A1974E.8070007@gmail.com> <CA+S5htN_SJxUiQXqaTUu71E1m=8nbCSp2=WUgN522S2Q2805JA@mail.gmail.com>
 <54A1A04B.1080104@php.net>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: Re: [PHP-DEV] Bugfest
From: jacob.bednarz@gmail.com (Jacob Bednarz)


> My previous suggestion was to have a contributors page and it will rank
> people based on bug fixes.

There appears to be a trend emerging where frameworks are making this more 
of a feature on their sites and there's nothing people enjoy more than 
getting recognition for their effort - even if it's just a place on a 
ladder. Some examples:

- Symfony: http://symfony.com/contributors
- Ruby on Rails: http://contributors.rubyonrails.org

> We definitely need somebody triaging old bugs. The problem is it
> requires a real lot of time, and is mind-numbingly boring, so not many
> people do it. Many bugs are low quality - missing data, not having good
> descriptions, etc

For someone new to the internals, this is a perfect place to start. While 
the knowledge of the internals is quite limited, debugging and triaging 
issues allows people to learn it in smaller and more managable chunks. I'm 
hoping to contribute here to level up my knowledge so hopefully that makes 
a positive impact - Even if it's "mind-numbingly boring" for starters. ;)

> Well, basic triage may be as simple as:
> 0) For all bugs that are older than 5.5
> 1) Look at the bug description. If the reproduction is not obvious from
> description, put it to "feedback" with request for better reproduction.
> If the submitter is no longer interested, it will be auto-closed as
> no-feedback with time.
> 2) Try to reproduce on 5.5/5.6. If it does not reproduce on either,
> close it with "not reproducible anymore, if you can reproduce on 5.6,
> please reopen".
> 3) If it reproduces on 5.6, put it in Verified status.

I quite like this approach as there is a large backlog of issues from 
versions which have reached end of life and may have been fixed in newer 
releases.