We'll need the summary/description/testing done to be more fleshed out, and follow our formatting guidelines: https://www.notion.so/reviewboard/Writing-Good-Change-Descriptions-10529e7c207743fa8ca90153d4b21fea
These fields get turned into the commit message, and the goal is to have people be able to understand a change from them.

Because this is a new evolution, it should go at the end of the sequence list rather than in the middle.

Two tiny issues left relating to the review request info:

Can you put the bug number into the "Bugs" field?

Please wrap your description to 72 columns.

Can you rewrite your summary to be in the imperitive mood, i.e., as if it were a command or an order.
If you substitute your summary into the following sentence it should make sense:
"This patch will <summary>"
(e.g., start the summary at "Allow")

The command in your testing done (... evolve --execute) doesnt need to have different code blocks on each line.

e.g.

The code block can `begin on one line
and end on the next.`

Python strings have this cool feature that you can split them over multiple lines like so:

my_str = (
    'this is my really cool '
    'multi-line '
    'and very long '
    'string.'
)


So we can format this as:

self.repository = Repository.objects.create(
    name='abcd'
         'def'
         'ghi' # ...
)```


*However*, we can also generate a very long string by doing:

```python
self.repository = Repository.objects.create(
    name='a' * 255,
    # ...
    )


which is shorter and more concise (and we know the string in question is 255 characters long without calculating it to verify the test).

Ship It!

Looks great!

Can you change this to Testing Repository.name with 255 characters? Having the specific thing being tested first is helpful for matching up tests with what's being tested.
The function can also just be test_repository_name_with_255_characters.

This looks great! Thanks!

Ship It!