Thank you James for the invitation. We are more than happy to join the
organisation and help communtiy in reviewing and merging pull requests. :)

Thank you for providing such detailed information, I have been through all
the links you have provided. I understand the role of a reviewer much
better now.

>Should the above be added to sugar-docs?
Very well written guidelines for any new member to the organisation. +1 for
sugar-docs from me.

Now that my exams are over, I look forward to a more active participation.
cheers!

On Fri, Feb 23, 2018 at 3:25 AM, James Cameron <qu...@laptop.org> wrote:

> Rahul and Yash, your code contributions have been consistently good
> for the past month, so I've invited you to the GitHub sugarlabs
> organisation so that you can review and merge pull requests.
>
> Information below may be of help to guide you in this task.
>
>
> My goals for review are;
>
> - detect trivial mistakes,
>
> - maintain consistent and good code quality,
>
> - reproduce test results, (especially for critical repositories),
>
> - maintain a useful git commit history for use by git bisect, and
>   developers who read it,
>
> - maintain other records, such as issues, tickets, and documentation,
>
> - not waste the time of the contributor, by doing myself anything
>   trivial that otherwise the contributor might have to do.
>
>
> Checklist for review of pull requests;
>
> - [ ] does the change have consensus of the community,
>       https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE
> _OF_CONDUCT.md
>       (if a reviewer is in doubt, seek opinions by @mentioning people)
>
> - [ ] does the commit message explain the summary, problem, and
>       solution, so that it can be used in future analysis,
>       https://github.com/sugarlabs/sugar-docs/blob/master/src/cont
> ributing.md#making-commits
>       (if a reviewer can fix it by squash or manual rebase, do so)
>
> - [ ] does the commit message reference the issue, bugs.sugarlabs.org
>       ticket number, or downstream ticket numbers,
>       (if a reviewer can fix it by squash or manual rebase, do so)
>
> - [ ] are the number of commits excessive for future analysis,
>       (a reviewer may squash or rebase if necessary)
>
> - [ ] is the changed code consistent in style with the existing code,
>       https://github.com/sugarlabs/sugar-docs/blob/master/src/desk
> top-activity.md#coding-standards
>       (on the other hand, expect flake8 changes to be in separate commits)
>
> - [ ] for critical repositories, does the change work properly on our
>       latest version of Sugar on either Fedora, Debian, or Ubuntu.
>
>
> Critical repositories are;
>
> - sugar, sugar-toolkit, sugar-toolkit-gtk3, sugar-artwork,
>   sugar-datastore, gst-plugins-espeak,
>
> - each of the Fructose activity set repositories,
>   https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Fructose
>
>
> Comments?  Should the above be added to sugar-docs?
>
> --
> James Cameron
> http://quozl.netrek.org/
>
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to