This should be included above with the other reviewboard imports, listed alphabetically.

When there's only a summary, the trailing """ should be on the first line.

I think we should be explicit about what we pull out. As discussed, we'll also need to transform url to path and stuff.

Docstrings are always in one of the following two forms:
"""One-line summary."""

or:
"""One-line summary

Multi-line description.
"""

As discussed, hould be path and mirror_path.

I think any extra data should be explicitly provided in an extra_data field in the constructor, and stored in a matching field in the class.

Same comment above about the docstring.
Documentation should always be clear about what's being returned. Instead of "maybe instances," the body of the docstring should say "This will return a list of zero or more HostingServiceRepository objects."

Same comment about import order.

This function needs a docstring matching the format of the previous docstrings.

This looks indented too far.
Also, the trailing brace should match the beginning of the line opening the brace (so, same level as repos)

This should specifically compare the fields we care about.

This looks great.
All my comments are about the style we like for code going into the product. This is the subjective stuff, which means there's not really a "right or wrong," but we like consistency :)

There should still be two blank lines here.

No blank line here.
The "# personal repos" should go on the next line.
General comment about comments: They should generally be proper sentences, with sentence caps and (when appropriate) trailing periods.

Maybe add a body to this docstring, talking about how this is used to represent a configured repository already on the hosting service, and does not necessarily match a repository configured on Review Board.

Our general form for test names will be like: "test_<funcname>with<conditions>"
Same below.

All the docstrings should be in the form of "Testing GitHub.get_remote_repositories with ..."
This helps us identify things when tests fail.
Also, as a special exception to the docstring rules, if the docstring reaches beyond the 79th column, you can wrap to the next line. This isn't typically allowed for unit test (it'll cut things off), but we use some custom stuff to allow it.
(I'd also change "repos" to "repositories", given that. Same below.)

Indented too far, and the {} shouldn't be grouped with the []. Should be like:
repos = [
    {
        'id': ...,
        ...
    },
    {
        ...
    }
]

You also shouldn't have the u prefix in front of strings.
We also like single-quote strings instead of double-quote, and we like trailing commas on the last item in any list or dictionary.

Same comments here about our preferred syntax for things.
Also the ones below.

There's a trailing space before the """

Blank line before this.

You should be able to use api_get instead of http_get, which will also do the json_loads and handle errors in the payload.

And before this.

And between these.

Summary must be on the same line as the """.

This regex should be pulled out and compiled into a regex on the class.

'next' is a reserved word in Python.

Blank line between these.

No blank line.

What is type? Can we make this a more descriptive name?

This shouldn't be a classmethod.

Needs to be 2 blank lines.

No trailing period.
Same below.

Shouldn't use the u prefix for strings.
Also, we prefer single quotes for strings whenever possible.
Same below.

Can't this be false?
Same below.

true?

Blank line before conditionals.

next is a reserved word. Maybe just put this inline below.

No trailing period.
Same below.

You still have some open issues from previous reviews. Can you verify whether those are fixed, and close them if so?
I also see a little bit of code duplication between this and /r/5602/. What depends on what here?

This should use self.next_link

The first line of this file should be:

from __future__ import unicode_literals

Thanks Olesssia! I've made some changes to get this working again (we had some refactoring of the GitHub code that broke your change), and made a few other small organizational changes. Otherwise, very much intact, and we'll be using this as the base for new work going into (hopefully) 2.1!
Going to close this in favor of the updated change, since we don't have the ability to transfer ownership yet.