Skip to content

Conversation

@jcs-odoo
Copy link
Contributor

@jcs-odoo jcs-odoo commented Mar 19, 2021

As you suggested it, @AntoineVDV , here is an addition about media filenames in the content guidelines.

@jcs-odoo jcs-odoo requested a review from AntoineVDV March 19, 2021 14:51
@AntoineVDV AntoineVDV changed the base branch from 11.0 to 12.0 March 19, 2021 15:13
@jcs-odoo jcs-odoo force-pushed the 11.0-media-filenames-jcs branch from 01eed50 to 0e4ca79 Compare March 19, 2021 15:21
@jcs-odoo jcs-odoo added this to the 12.0 milestone Mar 19, 2021
@jcs-odoo jcs-odoo requested a review from jubodoo March 19, 2021 15:24
@jcs-odoo jcs-odoo force-pushed the 11.0-media-filenames-jcs branch from 0e4ca79 to ec67956 Compare March 22, 2021 13:50
@jcs-odoo
Copy link
Contributor Author

@AntoineVDV @jubodoo
does this seem good like this to you?

I wondered if to indicate that they had to be in the "media" folder but I assumed most users would do it correctly without reading this anyway.

Cheers

@jcs-odoo jcs-odoo force-pushed the 11.0-media-filenames-jcs branch from ec67956 to 1ea6a0c Compare April 1, 2021 16:07
@jcs-odoo
Copy link
Contributor Author

jcs-odoo commented Apr 1, 2021

@AntoineVDV @jubodoo
Hello :)
I updated this one about media files following Antoine's comments + a new "rule" : one RST file = one media folder for this document only, as described in the doc.
If you agree with this suggestion and we merge this PR, it will change the repository's files organization.

Cheers,
Jonathan

@jcs-odoo jcs-odoo changed the title [IMP] guidelines: add media filenames section in content guidelines [IMP] guidelines: add media files section in content guidelines Apr 1, 2021
@jcs-odoo jcs-odoo requested a review from AntoineVDV April 1, 2021 16:12
@jcs-odoo jcs-odoo force-pushed the 11.0-media-filenames-jcs branch 3 times, most recently from a4d42d8 to 9447ed3 Compare April 2, 2021 09:21
@jcs-odoo jcs-odoo requested a review from AntoineVDV April 2, 2021 09:21
@jcs-odoo jcs-odoo force-pushed the 11.0-media-filenames-jcs branch from 9447ed3 to ef89d03 Compare April 2, 2021 09:37
@AntoineVDV AntoineVDV merged commit 0d258c1 into 12.0 Apr 2, 2021
@AntoineVDV AntoineVDV deleted the 11.0-media-filenames-jcs branch April 2, 2021 09:59
AntoineVDV added a commit that referenced this pull request May 19, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
AntoineVDV added a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2026
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2064
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2068
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2067
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2066
robodoo pushed a commit that referenced this pull request May 20, 2022
Since #903, the guideline for the location of new
resource (images, downloadable files, RST includes...) files is to place
those inside the directory of the RST page that references them.

For example, if `doc1.rst` has a reference to `image.png` and to
`download.zip`, the file structure should look like this:

├── parent_doc/
│     └── doc1/
│     │     └── image.png
│     │     └── download.zip
│     └── doc1.rst
│     └── doc2.rst
├── parent_doc.rst

Before this commit, most of the resource files were still located inside
'media' directories holding all the resource files referenced by RST
pages located at the same level as these directories. In the example
above, a single 'media' directory would hold all the resource files
referenced by both `doc1.rst` and `doc2.rst`. Doing so prevented us from
figuring out easily which resource file was referenced by which RST page
and, thus, lead to unused resource files piling up in the repository. It
also made it more complicated to define codeowners regex rules because a
team could not simply be assigned to `/some_page.*` but needed to be
assigned to both `/some_page\.rst` and to the location of 'media'.

In order to help new content writers figure out the guideline when
taking examples from other RST pages, this commit retroactively applies
the guideline to existing resource files and 'media' directories. The
left-over resource files that are not referenced by any RST page are
removed.

task-2497965

Part-of: #2065
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants