User talk:SAKryukov: Difference between revisions

Line 603:

:::::::::::::::::::: Yes, the earlier post does in fact seem to knock out the uncommitted post while the other person is still editing, so there's that. If revision control involves a program I don't have I might not be able to use it- then again, revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles, and you and I both seem to be spectacularly prone to typos, even though you use revision control all the time. Revision control on my end is more likely when I'm attempting to edit another type of document. That said, I do think Xenwolf should walk you through the procedure of preventing the complete loss of those uncommitted posts for good measure, and I asked him about it. --[[User:Aura|Aura]] ([[User talk:Aura|talk]]) 07:14, 9 December 2020 (UTC)

::::::::::::::::::::: Okay, probably we understand how such posts conflict. Now, "revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles"? No, I think you are not right. 1) In the present situation, there is no difference between articles and talks, so revision control would be equally useful. 2) In better situation, say, on GitHub where wiki is fundamentally integrated, the talk looks "more talkative", much closer to the chat software, which is much more usable: people are not working at the same document. Instead, each post goes in a separate section, everything is automatic, you don't have to do ~~this~~ very annoying indents, and yet it's quite apparent which comment you are commenting. And when people work at the same document, this is just a work at a file, no matter if this is a wiki or any other file, same revision-controlled behavior. Also, there are no special "Talk" pages, which is also very good. Instead, a discussion can be opened on every event, first of all, a commit pushed to the central repository. A commit, release, tag, some action, but not a file. This is very logical: what we discuss? Not a file itself, but rather a decision: adding a bunch of tiles, changing them, a request, and so on. It absolutely cannot prevent any free discussions. Say, you request some approval from members for the decision affecting others? Okay, we discuss it first, then decide together. It is not related to actual permissions, we can use different permission policies, from a very free one to a very strict. Mediawiki is great, simple but just overly generalized, maybe oversimplified: the concept of Talk is no different from an article, so we don't have chat-specific features, so this is not so convenient in first place. Maybe you simply need to look at such systems where wiki is integrated with revision control, then you would have a better feel of it. — [[User:SAKryukov|SA]], ''Wednesday 2020 December 9, 08:03 UTC''

::::::::::::::::::::: Okay, probably we understand how such posts conflict. Now, "revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles"? No, I think you are not right. 1) In the present situation, there is no difference between articles and talks, so revision control would be equally useful. 2) In better situation, say, on GitHub where wiki is fundamentally integrated, the talk looks "more talkative", much closer to the chat software, which is much more usable: people are not working at the same document. Instead, each post goes in a separate section, everything is automatic, you don't have to do these very annoying indents, and yet it's quite apparent which comment you are commenting. And when people work at the same document, this is just a work at a file, no matter if this is a wiki or any other file, same revision-controlled behavior. Also, there are no special "Talk" pages, which is also very good. Instead, a discussion can be opened on every event, first of all, a commit pushed to the central repository. A commit, release, tag, some action, but not a file. This is very logical: what we discuss? Not a file itself, but rather a decision: adding a bunch of tiles, changing them, a request, and so on. It absolutely cannot prevent any free discussions. Say, you request some approval from members for the decision affecting others? Okay, we discuss it first, then decide together. It is not related to actual permissions, we can use different permission policies, from a very free one to a very strict. Mediawiki is great, simple but just overly generalized, maybe oversimplified: the concept of Talk is no different from an article, so we don't have chat-specific features, so this is not so convenient in first place. Maybe you simply need to look at such systems where wiki is integrated with revision control, then you would have a better feel of it. — [[User:SAKryukov|SA]], ''Wednesday 2020 December 9, 08:03 UTC''

::::::::: Also, only today I faced the problem with sound degraded with time, don't know how to reproduce; this problem was never exposed with the rest of the applications based on the same synthesis engine. That problem may take time... — [[User:SAKryukov|SA]], ''Wednesday 2020 December 9, 00:01 UTC''

@@ Line 603: / Line 603: @@
 :::::::::::::::::::: Yes, the earlier post does in fact seem to knock out the uncommitted post while the other person is still editing, so there's that.  If revision control involves a program I don't have I might not be able to use it- then again, revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles, and you and I both seem to be spectacularly prone to typos, even though you use revision control all the time.  Revision control on my end is more likely when I'm attempting to edit another type of document.  That said, I do think Xenwolf should walk you through the procedure of preventing the complete loss of those uncommitted posts for good measure, and I asked him about it. --[[User:Aura|Aura]] ([[User talk:Aura|talk]]) 07:14, 9 December 2020 (UTC)
-::::::::::::::::::::: Okay, probably we understand how such posts conflict. Now, "revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles"? No, I think you are not right. 1) In the present situation, there is no difference between articles and talks, so revision control would be equally useful. 2) In better situation, say, on GitHub where wiki is fundamentally integrated, the talk looks "more talkative", much closer to the chat software, which is much more usable: people are not working at the same document. Instead, each post goes in a separate section, everything is automatic, you don't have to do this very annoying indents, and yet it's quite apparent which comment you are commenting. And when people work at the same document, this is just a work at a file, no matter if this is a wiki or any other file, same revision-controlled behavior. Also, there are no special "Talk" pages, which is also very good. Instead, a discussion can be opened on every event, first of all, a commit pushed to the central repository. A commit, release, tag, some action, but not a file. This is very logical: what we discuss? Not a file itself, but rather a decision: adding a bunch of tiles, changing them, a request, and so on. It absolutely cannot prevent any free discussions. Say, you request some approval from members for the decision affecting others? Okay, we discuss it first, then decide together. It is not related to actual permissions, we can use different permission policies, from a very free one to a very strict. Mediawiki is great, simple but just overly generalized, maybe oversimplified: the concept of Talk is no different from an article, so we don't have chat-specific features, so this is not so convenient in first place. Maybe you simply need to look at such systems where wiki is integrated with revision control, then you would have a better feel of it. &mdash;&nbsp;[[User:SAKryukov|SA]],&nbsp;''Wednesday&nbsp;2020&nbsp;December&nbsp;9,&nbsp;08:03&nbsp;UTC''
+::::::::::::::::::::: Okay, probably we understand how such posts conflict. Now, "revision control in talk pages doesn't seem to make as much sense as revision control in the actual articles"? No, I think you are not right. 1) In the present situation, there is no difference between articles and talks, so revision control would be equally useful. 2) In better situation, say, on GitHub where wiki is fundamentally integrated, the talk looks "more talkative", much closer to the chat software, which is much more usable: people are not working at the same document. Instead, each post goes in a separate section, everything is automatic, you don't have to do these very annoying indents, and yet it's quite apparent which comment you are commenting. And when people work at the same document, this is just a work at a file, no matter if this is a wiki or any other file, same revision-controlled behavior. Also, there are no special "Talk" pages, which is also very good. Instead, a discussion can be opened on every event, first of all, a commit pushed to the central repository. A commit, release, tag, some action, but not a file. This is very logical: what we discuss? Not a file itself, but rather a decision: adding a bunch of tiles, changing them, a request, and so on. It absolutely cannot prevent any free discussions. Say, you request some approval from members for the decision affecting others? Okay, we discuss it first, then decide together. It is not related to actual permissions, we can use different permission policies, from a very free one to a very strict. Mediawiki is great, simple but just overly generalized, maybe oversimplified: the concept of Talk is no different from an article, so we don't have chat-specific features, so this is not so convenient in first place. Maybe you simply need to look at such systems where wiki is integrated with revision control, then you would have a better feel of it. &mdash;&nbsp;[[User:SAKryukov|SA]],&nbsp;''Wednesday&nbsp;2020&nbsp;December&nbsp;9,&nbsp;08:03&nbsp;UTC''
 ::::::::: Also, only today I faced the problem with sound degraded with time, don't know how to reproduce; this problem was never exposed with the rest of the applications based on the same synthesis engine. That problem may take time... &mdash;&nbsp;[[User:SAKryukov|SA]],&nbsp;''Wednesday&nbsp;2020&nbsp;December&nbsp;9,&nbsp;00:01&nbsp;UTC''