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

(Semi-)permanent links for motions #453

Open
Nanush7 opened this issue Jan 21, 2025 · 5 comments · May be fixed by #456
Open

(Semi-)permanent links for motions #453

Nanush7 opened this issue Jan 21, 2025 · 5 comments · May be fixed by #456
Assignees

Comments

@Nanush7
Copy link
Member

Nanush7 commented Jan 21, 2025

Whenever a motion is amended, its number changes. This means that any link that points to the motion's document stops working. This makes it necessary to update several documents, and we often forget to do so.

It would be easier to have permanent (or at least semi-permanent) links to motions (e.g., by their name, ignoring the number). The only reason I see to keep the links as they are, is to make it clear that a referenced motion has been updated since it was referenced (e.g., if referenced in an announcement or email).

If we want to proceed with this idea, I'm willing to have a look and propose the required changes.

@dmint789
Copy link
Member

Yes, this is something the Board wanted us to do. What kind of solutions do you have in mind?

@dmint789
Copy link
Member

Keep in mind, the solution should also make it so that links linking to the old version of each motion don't break. Perhaps, the built files should just exclude the date part from the end of the file name of each motion.

@Nanush7 Nanush7 self-assigned this Jan 28, 2025
@Nanush7
Copy link
Member Author

Nanush7 commented Jan 28, 2025

Keep in mind, the solution should also make it so that links linking to the old version of each motion don't break

Is that a new feature we want? There's no way to access previous versions of the motions currently (apart from doing it via git).

the built files should just exclude the date part from the end of the file name of each motion

Yeah, that's an example I mentioned in the description, I think it would be the easiest way to do it.

To make it possible to have permanent links to historical versions, we can also store the files in directories by month and year on S3 (so that, for example, the URL would look like .../documents/motions/2025.1/Spirit.pdf), if the WST is fine with that. The latest version of each document should be stored on a separate directory (e.g. .../documents/motions/latest/Spirit.pdf). This would give you the option to make a link always point to the latest version, or to a specific version.

@dmint789
Copy link
Member

Keep in mind, the solution should also make it so that links linking to the old version of each motion don't break

Is that a new feature we want? There's no way to access previous versions of the motions currently (apart from doing it via git).

the built files should just exclude the date part from the end of the file name of each motion

Yeah, that's an example I mentioned in the description, I think it would be the easiest way to do it.

To make it possible to have permanent links to historical versions, we can also store the files in directories by month and year on S3 (so that, for example, the URL would look like .../documents/motions/2025.1/Spirit.pdf), if the WST is fine with that. The latest version of each document should be stored on a separate directory (e.g. .../documents/motions/latest/Spirit.pdf). This would give you the option to make a link always point to the latest version, or to a specific version.

I meant that moving forward, all links should be version-agnostic, so that links don't break in the future. We don't need to make past versions available.

@Nanush7
Copy link
Member Author

Nanush7 commented Jan 28, 2025

Well, in that case, I guess it's as easy as removing the number from the file name.

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 a pull request may close this issue.

2 participants