Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed #30624 -- Changed docs to use numbered list reStructuredText syntax. #11546

Closed
wants to merge 1 commit into from
Closed

Conversation

jdufresne
Copy link
Member

The numbered list syntax simplifies future maintenance:

  • As items are added or removed, the rendered items are automatically
    renumbered.

  • If a long list happens to reach double digits, all items remain
    indented the same.

https://code.djangoproject.com/ticket/30624

…ntax.

The numbered list syntax simplifies future maintenance:

- As items are added or removed, the rendered items are automatically
  renumbered.

- If a long list happens to reach double digits, all items remain
  indented the same.
Copy link
Member

@felixxm felixxm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdufresne Thanks for this patch 👍 I think we should leave the old release notes untouched.

@felixxm felixxm self-assigned this Jul 8, 2019
Copy link

@wreis wreis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

@jdufresne
Copy link
Member Author

I think we should leave the old release notes untouched.

Why?

These are docs to be maintained just as any others through best practices and project standards. The rendered content of these docs aren't changing, merely the raw code form to conform to the larger project. IMO, we should apply this best practice everywhere it can be and makes sense to. Over the long term, code has a tendency to be copied or examined by others as an example. By fixing the old release notes as well, it helps signal to new contributors how new changes should look.

@felixxm
Copy link
Member

felixxm commented Jul 8, 2019

The aim of this change is to simplify future maintenance, we don't need to simplify maintenance of old release notes, IMO.

@carltongibson
Copy link
Member

carltongibson commented Jul 8, 2019

TBH, I don't think we should make this change on mass at all. For me, it's very little benefit for quite a lot of changes in the blame view. (I see the point in lists or changes to lists going forward.)

I agree with @felixxm re the old release notes.

@jdufresne
Copy link
Member Author

For me, it's very little benefit for quite a lot of changes in the blame view.

This really depends on tooling. I use Emac's vc-annotate, which offers a hotkey to "Visit the annotation of the revision before the revision at line." So it is extremely easy to skip over uninteresting annotated lines. Other tools offer this same feature, including GitHub's blame view. Further, there are even more advanced tools such as git-hyper-blame. My point is, the tools handle this concern, pick your favorite to work with.

@carltongibson
Copy link
Member

Yes, there are tools. But they raise the barrier to entry at the very least.

On balance, looking at this, I don't see the cost at justifying the benefit: we make the history more opaque for everyone for a minor gain.

I appreciate others (you 🙂) may make that judgement differently.

@felixxm
Copy link
Member

felixxm commented Jul 9, 2019

@jdufresne Many thanks for this patch, but I agree with Carlton.

Closing per ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants