adding a news model item with a date far in the future only for reference #1403
No reviewers
Labels
No Label
bug
build
cgi Scripting
design
disruptive
documentation
duplicate
easy
feature-request
help wanted
javascript
priority/low
question
system-hackers
tagging
text
translations
wait/bugfix
wait/inprogress
wait/misc
wait/proofread
wontfix
xsl
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: FSFE/fsfe-website#1403
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "20200525-model-news-item"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi @max.mehl , this is the model news item uploaded with a maximum date in the future as suggested by Matthias. As this is a model news-item I also did not use correct tag-descriptions but still real tags (to not create new ones). I chose the most-used ones. Also the discourse-link is fake of course. Please check if this is ok for you to merge it.
How does this relate to #1346 ?
@eal I am also not sure why we need this. The templates in #1346 should be ready for copy, so I'm not sure why we should create a "real" news item?
This was part of my job to create a pr-checklist. It was wished to have a model news-item that explains everyone in a easy-to-understand and easy-to-adapt way how to write a good news-item. It is linked for example from here: https://wiki.fsfe.org/Internal/PublicationChecklist
I think these two things serve very different purposes. Your templates are very technical while this proposed news-item is more about "the writing itself". It can be shown as a role model to everyone/volunteers who like to write something for the fsfe news pages.
I'd have some remarks/improvements about the way the text in this file is formatted as well as about some things said in the text (for example the point about "technical quotes"). However I think we should first clarify whether this will be put online at all before we spend time on this.
adding @mk to the discussion, as I think he is also in favor of having this.
I agree that the purposes are different. For instance, I would like to have a XHTML file that I can just copy and fill with my content, and which reminds me of the tags to use.
Your approach is similar, but in order to fulfil my wish, I'd have to delete loads of text. However, this is not saying that your approach is wrong.
But, I see the problem of having two files which we would have to keep in sync when some formatting/tag would change...
When we update the example-text with all other html-tags you like to see included we can maybe fulfill both approaches in one? This way people have to delete some text every time, but on the other hand it also always reminds them about good writing style.
The idea of the text was also written with other people and volunteers in mind who write news very rarely for us. If we update it with your html I think we can serve both needs.
I do not have a strong preference. I see some advantages and disadvantages for both approaches. The advantage would be that all documenation is in one file. The disadvantage is that you have to delete parts and furthermore I am unsure if all of the documentation on this should be public.
I would put this example on the wiki page itself using the
{{{code}}}
syntax. This is documentation that can easily be mistaken for production content intended for publication, so it should not live in the production repository.Alternatively or additionally the same content could be integrated into the templates of #1346 as XML comments. These would be trivial to remove using grep/sed/awk/vim and would be harmless in any case.
In any case, I recommend closing this pull request without merging into master.
I strongly suggest not to store duplicated information in the repo and the wiki. So if we have a template article, it should only live in one of these places.
I see more practical benefit in having a template in the repo, so editors can just copy it and move on, instead of going to a wiki page. Also, this helps us when we change the syntax with git-sed or so, as we will then automatically update these templates as well – I bet no one will check the wiki when doing so.
Whether we need the content to live in the template is another story, but the comments would be an option.
Pull request closed