Topics

A potential best practice


Emily Ratliff <eratliff@...>
 

Hi,

Someone pointed me to this list of projects which maintain a list of "easy bugs" for beginners to work on, so that they can gain experience with contributing to the project: https://openhatch.org/wiki/Easy_bugs_for_newcomers

To me, the presence of an "easy bugs" list represents a very advanced "best practice". There are really very few projects on the list. Projects that have these lists are planning for the long term viability of their project. The bugs on the list are necessarily not security related bugs. 

Do you think the fact that a project maintains an "easy bugs" list would be a useful metric to include in the badging program to indicate a very high level of maturity?

Will the badging program have the concept of optional, but recommended practices? This might be something that we document as a best practice but do not include in the badging program at any level.

Thanks,

Emily


David A. Wheeler
 

Someone pointed me to this list of projects which maintain a list of "easy bugs" for beginners to work on, so that they can gain experience with contributing to the project: https://openhatch.org/wiki/Easy_bugs_for_newcomers
Nice list. Not complete, of course, and that just strengthens your point. For example, I know that OWASP ZAP also maintains a list of “easy” bugs; they label them on GitHub’s issue tracker as IdealFirstBug. See: https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3AIdealFirstBug

To me, the presence of an "easy bugs" list represents a very advanced "best practice". There are really very few projects on the list. Projects that have these lists are planning for the long term viability of their project. The bugs on the list are necessarily not security related bugs.
Do you think the fact that a project maintains an "easy bugs" list would be a useful metric to include in the badging program to indicate a very high level of maturity?
Will the badging program have the concept of optional, but recommended practices? This might be something that we document as a best practice but do not include in the badging program at any level.
I like it... that way we can *suggest* good things once people have the basics in order.

I think we should continue collecting a larger set of *possible* best practices, and then select down to the ones that would be directly measured. Some of them might be of the flavor "do at least X of these". The ones that aren't selected as "primary" measures would be good candidates for these "recommended" items (whatever they are called).

--- David A. Wheeler


Emily Ratliff <eratliff@...>
 

I will let the Open Hatch Easy Bugs maintainer know about OWASP ZAP - that is really nice.

Are we ready for a github to serve as a collection point for the main ideas?

Thanks!

Emily

On Wed, Jul 22, 2015 at 12:04 AM, Wheeler, David A <dwheeler@...> wrote:
> Someone pointed me to this list of projects which maintain a list of "easy bugs" for beginners to work on, so that they can gain experience with contributing to the project: https://openhatch.org/wiki/Easy_bugs_for_newcomers

Nice list.  Not complete, of course, and that just strengthens your point.  For example, I know that OWASP ZAP also maintains a list of “easy” bugs; they label them on GitHub’s issue tracker as IdealFirstBug.  See: https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3AIdealFirstBug

> To me, the presence of an "easy bugs" list represents a very advanced "best practice". There are really very few projects on the list. Projects that have these lists are planning for the long term viability of their project. The bugs on the list are necessarily not security related bugs.
> Do you think the fact that a project maintains an "easy bugs" list would be a useful metric to include in the badging program to indicate a very high level of maturity?
> Will the badging program have the concept of optional, but recommended practices? This might be something that we document as a best practice but do not include in the badging program at any level.

I like it... that way we can *suggest* good things once people have the basics in order.

I think we should continue collecting a larger set of *possible* best practices, and then select down to the ones that would be directly measured.  Some of them might be of the flavor "do at least X of these".  The ones that aren't selected as "primary" measures would be good candidates for these "recommended" items (whatever they are called).

--- David A. Wheeler



Dan Kohn <dankohn@...>
 


--
Dan Kohn <mailto:dankohn@...>
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000

On Wed, Jul 22, 2015 at 3:46 PM, Emily Ratliff <eratliff@...> wrote:
I will let the Open Hatch Easy Bugs maintainer know about OWASP ZAP - that is really nice.

Are we ready for a github to serve as a collection point for the main ideas?

Thanks!

Emily

On Wed, Jul 22, 2015 at 12:04 AM, Wheeler, David A <dwheeler@...> wrote:
> Someone pointed me to this list of projects which maintain a list of "easy bugs" for beginners to work on, so that they can gain experience with contributing to the project: https://openhatch.org/wiki/Easy_bugs_for_newcomers

Nice list.  Not complete, of course, and that just strengthens your point.  For example, I know that OWASP ZAP also maintains a list of “easy” bugs; they label them on GitHub’s issue tracker as IdealFirstBug.  See: https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3AIdealFirstBug

> To me, the presence of an "easy bugs" list represents a very advanced "best practice". There are really very few projects on the list. Projects that have these lists are planning for the long term viability of their project. The bugs on the list are necessarily not security related bugs.
> Do you think the fact that a project maintains an "easy bugs" list would be a useful metric to include in the badging program to indicate a very high level of maturity?
> Will the badging program have the concept of optional, but recommended practices? This might be something that we document as a best practice but do not include in the badging program at any level.

I like it... that way we can *suggest* good things once people have the basics in order.

I think we should continue collecting a larger set of *possible* best practices, and then select down to the ones that would be directly measured.  Some of them might be of the flavor "do at least X of these".  The ones that aren't selected as "primary" measures would be good candidates for these "recommended" items (whatever they are called).

--- David A. Wheeler



_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges