User talk:Aroko

From ArchWiki
Revision as of 12:17, 13 October 2011 by Aroko (talk | contribs)
Jump to: navigation, search

Some advices and requests

Hello and welcome to the ArchWiki.

I would like to ask you to explain here (in detail, if needed) the overall scheme at the base of your recent edits to:

It looks like you have deleted some content without providing an explanation, and that is not customary here.

Please remember that there are users who habitually and voluntarily check all the edits that are done to the articles, to try to prevent pages from being damaged, and keeping them clean and tidy, for everybody's sake. Right above to the save button in edit pages you will find the "Summary" field, where you would be required to briefly provide a description of your edit, also specifying the reasons which led you to do it. Failing to do so, you make the work of the patrolling users much much harder, because they have to figure out what you did and why all by themselves, possibly even forcing them to directly contact you to get an explanation, like in this very case.

I hope you will understand, there are currently more than 12,000 registered users on this wiki (continuously growing), and several dozens of edits are performed every day, so we all have to try and collaborate in the tidiest and most considerate way.

Thank you for cooperating. -- Kynikos 14:33, 12 October 2011 (EDT)

Hi, Kynikos! It's nice somebody noticed my work. Firstly, I haven't deleted anything. I've just moved content from one location to another where it is more appropriate. So lets begin with 1. Bash. I have created additional page Readline and moved in there everything that has something to do with it. Now it's much more clear that Readline is responsible for your shortcuts, macros and history management. So next time a user wonders how to delete a word on the command line he will know where he should look for. Note, that information about interacting with command line hasn't disappeared completely from Bash page. It is introduced briefly and then the link to Readline page is given. 2. I've created new stub article Command shell. This article should introduce users to the notion of shell, its tasks in operating system. Also, all flavors of shell which can be found on Arch wiki should be briefly discussed there. 3. Command line tools -- I've changed nothing in there. 4. Core Utilities -- as the name of the article already states it, the article is about core utilities. So examples how to create aliases and functions in bash (!! core utilities have nothing to do with bash) have nothing to do there. So I've moved them to Bash#Aliases and Bash#Functions where they fit just perfectly! 4. Now about this 2 weeks discussion about obvious thing. I'll just repeat and add some new points. a)the environment variables are NOT bash specific and users of ALL shells should be aware of them; b)only some random environment variable were listed there and there was not empty intersection with Environment Variables page. So I think it's pretty obvious that corresponding content from bash article should be moved to Environment Variables article. At least, I am sure the discussion of this question should not last 2 (!!!) weeks. Lets keep discussions short!
In the future I will add comments to my changes. And thank you for telling me how to leave my signature. It was lat in the night yesterday and I was lazy to look for this macro. My fault.
Hope everything is clear now and you'll appreciate my contribution. Yours Aroko 16:18, 12 October 2011 (EDT).
You should not be surprised that somebody noticed your work, you have edited a public article after all, that is why you have to think well before editing articles, especially when doing major restructuring.
About Command Shell are you planning to add content in it? It can be a good idea, but it is pointless to create a stub and just expect others to work on it.
About Commandline Tools, you have removed it from Category:Command shells (English): is there a particular reason why you did that?
Overall you have had good ideas, but I have had to correct some mistakes you have made, and restore some content that you had indeed lost: please next time double-check your edits and be more accurate, so that we can learn to trust your edits more in the future.
About discussions, I would like you to understand, and this is very important for our peaceful cooperation on the wiki, that a 2-week-old open discussion is not old at all, nobody here works as a wiki editor, so everybody answers when he finds the time to do that, and those who are waiting for an answer should just patiently wait. In this particular case you should have better first added a reply to the discussion, then waited at least one day or two, and only then you could have started performing the edits, but only because it was clear that the discussion had almost, though not finally, arrived to an agreed decision.
-- Kynikos 19:20, 12 October 2011 (EDT)
Well, I do not know much about other shells, so I expect other 12,000 people to help me with Command Shell. However I will write introduction part in the near future. Also, I think the existence of this stub is important. It shows where the content is missing.
Ah, right I removed Commandline Tools from Category:Command shells (English). Hmmm.. the reason is simple, command line tools have nothing to do with shells (The only thing they have in common is that CLI tools can be run in shell). They should fall into category of apps or similar.
So about discussions. Do you realize that long discussions are a big barrier for new users to change something? And not even because they should hang around for weeks waiting for replies, but because they firstly need to read those loooong conversations. So I think it's completely ok if someone experienced enough comes and says: "Hey guys, you are wasting your time here. The solution is simple and it looks like this." Actually now I doubt the wiki collaboration style is effective at all. A lot of newcomers come and start to discuss, disappear for a week then discuss again. It would be much better if there are people responsible for some parts of the wiki and new users send patches to them. Responsible people (are experienced enough) can quickly decide whether the change should be accepted without long discussion. Once a person sent a number of reasonable patches this level of indirection can be omitted. Aroko 05:37, 13 October 2011 (EDT)
P.S. I'm sorry I've missed that paragraph about insecurity of . in PATH. I'll try to be more careful.
There are many things to be done on a wiki, it is not as though we all sit perched in front of our screens refreshing a certain talk page until a discussion is concluded. Consider it a triage system; important things are discussed more urgently, less important things are discussed less urgently. Sometimes conversations die off. Only in this triage system, the patients can be resurrected! (As the bash issue was.)
The wiki system works. But with a limited number of regular contributors, some things don't move at breakneck speed.
In contrast, I think your "patches" system introduces more hierarchy than is productive in a wiki, and is an even larger barrier to entry, since new users wouldn't feel like they have much real creative control autonomy or importance. | Emiralle 06:11, 13 October 2011 (EDT)
Well, wiki system works. It's obvious it works somehow otherwise it won't exist. But does it work in efficient way? That is the question. The patches system is the system used in all open source projects. Sending patches does not limit your creativity. It does not allow loooong discussions and produces high quality content. As I said once you have shown you are reasonable enough you can gain full control and be extremely creative. I understand some things need time. The question how to structure articles about applications is of that kind. But it's nonsense to have that long discussions about obvious things. Can you even remember after two weeks what was it all about?! You'd probably need to skim the whole disscussion once more each time... This is contra productive. Some notion of a experienced user should be introduced. He makes quick decisions. Be it a patch system or some another one. Feel free to suggest your approach. Approach that is efficient. Take a look at my recent changes. I've shuffled a couple of articles in half of an hour. And I'm sure you'll agree with those changes. How much time would I need to do the same starting a discussion each time? Multiply number of major content moves by two weeks and you will have the answer.
To summarize, yes existing approach is the most democratic one. Yes, the barrier is probably the lowest. But it's not efficient. I propose to find an efficient approach. Aroko 08:17, 13 October 2011 (EDT)