Alsee

Dear Alsee, Welcome to MediaWiki.org!

Yes, welcome! This site is dedicated to documenting the MediaWiki software, the software behind many wikis, including that of Wikipedia and the Wikimedia Foundation projects.
Please, take a look at the following pages. They might prove useful to you as a newcomer here:

• Landing instructions
• Project:About
• How does MediaWiki work?
• Help:Editing pages
• Frequently asked questions
• How to contribute

If you have any questions, please ask me on my talk page. Once again, welcome, and I hope you quickly feel comfortable here, and find this site useful documentation of the MediaWiki software.

Thanks, and regards, --Liuxinyu970226 (talk) 07:16, 5 September 2014 (UTC)

MV retrospective

I apologize for the condescending edit summary.

A retrospective reflects the impressions of the people who participated in a project. If you have comments, it would be better to put them on the talk page, or create another page and link it prominently from the retrospective page. --Tgr (WMF) (talk) 10:48, 1 March 2016 (UTC)

Tgr (WMF), no problem. That's a reasonable definition for the page. Alsee (talk) 16:16, 1 March 2016 (UTC)

I agree external perspective would be useful; would you be willing to write one somewhere? (FWIW the retrospective reflects the things team members agreed on; individual team members sometimes had starker views on some points. It's hard to state candid opinions publicly when anything you say is liable to be taken and used against coworkers - that's a problem our movement hasn't figured out yet, IMO, and it results in slightly watered-up documents like this one.) --Tgr (WMF) (talk) 23:37, 4 March 2016 (UTC)

Tgr (WMF), wow. I didn't think you guys would be interest in this. You didn't say anything specific about what happened, but nonetheless your comments were impressively candid. I imagine some of the staff were in a painfully impossible situation. I may need some time to get to it, but yeah, I can make one. Are you just looking for my individual comments? Or is this significant enough to get some other editors to collaborate on it more thoroughly?

I am really happy with the WMF's positive approach to the community recently. During the Media Viewer events I was one of the very critical voices. To be honest I'm feeling little guilty at the prospect of unloading a pile of old criticisms when things are going so well now. Alsee (talk) 02:02, 5 March 2016 (UTC)

Well I am interested (and appreciate that you are willing to spend your free time on this), don't want to talk in anyone else's name. The Multimedia team doesn't exist any more (somewhat confusingly, there is a Multimedia team, but it's a different one), but people in Reading (which is the current group responsible for reader-facing features) are very interested these days in figuring out how to have a constructive relationship with the community, so I might not be your only reader, but no guarantees :) I'm the only person in Reading who also worked on Media Viewer but others might be interested in learning from history. I don't think you should put too much effort into it though, there will probably be more important discussions soon (e.g. about the Gather RfC). --Tgr (WMF) (talk) 02:53, 5 March 2016 (UTC)

Understood.

Regarding the Gather RFC, to put it in a nutshell, at the moment many in the community are inclined to interpret any remotely ambiguous statement in the the most cynical manner possible. I'm hopeful that community members will start criticizing "unreasonable cynicism" when more people see what I'm seeing. Some of the liaison comments before the RFC were interpreted as trying to avoid/reject an RFC from happening (i.e. driving forwards an unstoppable project). During the RFC the community seriously shouldn't shouldn't have been blaming the WMF for opposing the outcome - there is no outcome until it closes. And to be fair, delivery of the outcome to the WMF should be treated as "first communication of an actual community request", and from that point the WMF is entitled to reasonable time to sort out a reaction. When the WMF did decide how to handle it, the WMF did so very reasonably and constructively. However the statements were not blindingly-explicit. Several community members read into those statements any remotely plausible interpretation of evasion, conflict, or rejection. Alsee (talk) 10:33, 5 March 2016 (UTC)

Adding ping: Tgr (WMF). Alsee (talk) 11:33, 5 March 2016 (UTC)

Milestone communication

I respectfully ask that you not edit pages related to the Technical Collaboration Guidelines. They are work-related and are the result of a lot of time and negotiation for wording. I appreciate your attempt to clarify something that you felt was a detrimental inference, but it's not the case. Use the talk page if you think something is in error rather than making assumptions. Keegan (WMF) (talk) 16:33, 22 July 2016 (UTC)

Discussion continued at Talk:Technical_Collaboration_Guideline/Milestone_communication, topic Clarification on intent. Alsee (talk) 02:04, 23 July 2016 (UTC)

Flow RfC

Doing the Flow RfC at en.wp before more Flow-promotional antics might be more practical. If a consensus against is as sure as you think, then a strong showing of rejection might be enough to see the project abandoned sooner rather than later.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:44, 25 August 2016 (UTC)

SMcCandlish ☺, it is tempting. However Flow has been a non-topic for a long time. The RFC would drop out of the sky for zero apparent reason. People who dislike the RFC would get riled up, viewing the RFC as a pointless and provocative move. When the survey is announced, or there is some other significant movement on Flow, then there will be a natural discussion on the topic. There will be a clear flurry of people interested in running it, and a clear reason for having an RFC to officially sort out consensus on the subject.

That said, I certainly have no opposition to anyone who wants to step up and post it now :) If you'd like to do so, or you'd like to help improve it, the current draft can be found at EN:User:BethNaught/Draft Flow RfC Alsee (talk) 22:16, 25 August 2016 (UTC)

I'll take your word for it; I have not been keeping any eye on Flow-related discussion on en.wp, so wasn't aware the topic was dormant.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:05, 26 August 2016 (UTC)

Ban

Hello, We received reports about your behaviour in several phabricator tickets related to flow. Even though we understand the importance of criticism of technical products and that being vital to improving the work, the committee finds your behaviour in violation of the Code of Conduct (specifically the ninth point in "Unacceptable behavior" part). Given that you have been warned before, the committee decides to ban you from acting on any flow-related task in phabricator for two months. Technically this ban can't be enforced but if you violate it, you immediately get a one-month complete ban from phabricator. We hope in future, you engage in discussions in a more civil and constructive manner and avoid making strong assumptions about other people's intentions. Best TechConductCommittee (talk) 21:43, 20 March 2018 (UTC)

Off-topic comment

Hello, Alsee!

I'd like to ask you to revisit your comment on the topic "Call for unexpected behavior" ([link]). To keep the topic focused and useful, please only post actual reports in the prescribed format on that topic. Your comment only contains complaints, no properly formatted report, so please post it in a separate topic, to not disrupt the work. I think it would be appropriate to delete or hide your comment. Please do so.

I understand that it's hard to get on the same wavelength with developers, I have the same general experience, even though I am a developer myself and I speak the same technical language as WMF developers. However, my experience with the Talk page team is that they are much more collaborative than other teams, respond to the majority of feedback and volunteer contributions, and when suggestions or problems are presented to them clearly, with exact examples, they do something about it, that will improve the outcome of the project.

On the other hand, I've repeatedly found that your input lacks an exact description of the issue that you perceive and clear examples, therefore I've asked you previously to focus on examples, which you have refused, claiming you've done that too many times years ago, but continued to make generalized claims of perceived issues. I assume those were real issues years ago - however you haven't shown those reports -, but the whole software stack has changed since then and those examples have to be tested again to see if they still cause issues and how to fix them. The problem is you don't show examples. I can assure you this kind of input is unusable, even with the best intentions.

The talk page team is doing a pretty good job in addressing issues and developing a tool that's been one of the most requested for many years. Even if some issues - that only you know of - will remain, the product is generally taking a good shape and will be very useful in the majority of the cases. The rest will be solved by using the source editor, or by users paying attention to not use weird, problematic constructs that I assume are the basis of your claims.

To be honest I have the impression that you can't reproduce those issues, or have never reported them before and just make this up. I might be wrong, so don't take this to your heart, but understand that your comments are unnecessarily dramatic, lacking any useful facts that would help to improve the product. I ask you again to stop making such comments. I'd suggest to take a course in QA (Quality Assurance) to learn how to test, find and report bugs, so you can positively contribute and help the development. I'm sorry if this comes down as a too strong opinion for you. As a developer, I find those kinds of comments the most depleting, which never result in any issue solved, just disruption. I hope I could explain this sufficiently and without hurting your feelings. Thank you for reading this and considering it. —Aron Man.🍂 edits🌾 20:20, 3 April 2020 (UTC)

Aron Manning:

1. During the Superprotect incident some people dismissed the objections and dire warnings from myself and others as melodrama. The result was that community fired&replaced every community-elected member of the Board. Those board members then fired&replaced every appointed member of the board. Shortly thereafter the new board accepted the Executive director's resignation (a.k.a. politely fired and replaced). Paychecks for the responsible mid-level management also terminated.
2. I and many other editors gave dire warnings that Flow was fatally flawed and doomed. Some people dismissed those warnings as melodrama. The result was that I organized consensus across three wikis, and I was going to continue as far as necessary, until development and deployment of Flow was terminated. Sooner or later we're going to have to deal with gigantic mess and technical debt of removing all of the Flow pages that have been scattered around.
3. I warned and begged and pleaded with the Liaison, the Product Manager, and the Executive director that the Gather project was headed was about to crash. They ignored my warnings, apparently treating it as melodrama. That resulted in a 97% hostile-consensus immediately killing the project.
4. I warned the Product Manager, the Liaison, and a different Executive Director that the SingleEditoTab was running into big trouble stealth-deploying a VE-default. In case you haven't noticed the pattern here yet - the warnings were ignored. Apparently they considered it melodrama. The result was that multiple wikis wrote hacks for the sitewide Javascript to override the product, and we came perilously close to another Superprotect level incident.
5. I warned the 2017Editor manager that design was fatally flawed and it could not be deployed unless it was fixed. He ignored the warnings, treating them as melodrama. The result was that I ran an RFC with overwhelming consensus to block deployment. Like Flow, the product has been a walking-corpse for the last two years. Apparently I'm going to have to organize further consensus to get it fully terminated.
6. I have little doubt that there has been one or more similar examples that I can't think of offhand.
7. I have informed the DiscussionTools manager that I am going to run an RFC seeking to block deployment of the product. You can call that "melodrama" - however I suggest "fact" will soon be the obviously-accurate term.

Many users explicitly stopped submitting bug reports on Flow because the Foundation's development&engagement processes were so grossly dysfunctional that not submitting bug reports was the most constructive option. It is important and constructive to ensure the Foundation is aware that happened, and it is important and constructive to alert the Foundation whenever a similar situation begins to arise again.

The manager knows what the problem is (pointlessly round tripping content through Parsoid causes a variety of content corruption and other problems). He knows how to fix it. He doesn't want to. The most constructive way to get the product fixed is to make sure the Foundation knows that the community won't let them deploy a deliberately broken product. Alsee (talk) 06:43, 5 April 2020 (UTC)

@Alsee: : Your answer avoids to address the problem:

The comment you made ([| link ]) in the topic "Call for unexpected behavior" does not follow the expected format and lacks an error report. It is disruptive to reporting actual errors. Will you correct this? — Preceding unsigned comment added by Aron Manning (talk • contribs) 5 April 2020‎

Aron Manning By your own logic, the most disruptive post there is yours.

My post is directly relevant to the thread. It contains information that is completely relevant and important to the subject. It reports a bug with the Foundation's process. The intent/hope is to improve the Foundation's current an future process. The intent/hope is to get constructive improvement to the design flaw, and to avoid flushing away money and precious dev-resources on worthless and futile work. Any work on symptoms of the flaw will be 100% wasted if/when the design flaw itself is fixed, and if the design flaw isn't fixed I expect any work on symptoms of the flaw will also be 100% wasted as I expect the community will reject deployment of a deliberately flawed product. Either way, working on symptoms of the flaw is a waste of money and a waste of precious dev labor. Any reasonable software development process on almost any product would immediately classify content corruption as a top priority must-fix. You are are literally arguing to advocate or defend content-corruption. How about we stop chattering about it and just fix it instead? Alsee (talk) 05:10, 6 April 2020 (UTC)

How about we stop chattering about it and just fix it instead?

Good idea. For that you should start creating bug reports. In 4 months you've made zero.

The rest of your comment is similarly baseless and evasive. Indeed, you should stop chatting up this nonsense. There are processes that need to be followed, but you refuse to. What you are actually doing wastes time and causes disruption. Please look back on your actions in the last months and evaluate the proportion of issues reported compared to the walls of text you've written, then reconsider how you want to continue contributing and how you could do that constructively. —Aron Man.🍂 edits🌾 11:32, 6 April 2020 (UTC)

Ban 2

Hello, We received several reports of ongoing violations of our Code of Conduct made by you. You were banned from acting on everything related to Flow in Phabricator back in 2018. Given that this is a repeated behaviour, we hereby ban you from interacting on anything related to Flow indefinitely, we ban you from interacting with members of the Editing team (WMF) on Phabricator for 3 months. Should you break this ban, we will perform an actual ban from Phabricator for 3 months.

Please understand the Code of Conduct exists to ensure a healthy and collaborative environment for all technical contributors, staff and volunteers alike. We hope that with time, you will be able to make valued contributions in a way that is respectful to others, and does not disrupt their work or make them feel pressured.

Thank you for your understanding and cooperation.

Amir on behalf of Code of Conduct committee Ladsgroup (talk) 05:12, 18 May 2020 (UTC)

Ladsgroup I have a process question.

In the community, there would normally be evidence presented, public process, and a clear explanation of what the issue(s) were. Aside from general concerns of fairness, I believe is is considered essential for an effective problem-solving process that the individual to understand what the issue is in order to be able to avoid it in the future.

I understand Phabricator is an independent process, but it appears to lack the elements identified above. I am asking does the Phabricator process include or make available any evidence, public process, and/or clear explanation? Alsee (talk) 13:11, 18 May 2020 (UTC)

CoC and its confidentiality section bars us from disclosing evidence as it might lead to disclosing identity of the reporter(s). If you want to have a fair trial, as outlined by CoC itself, you can appeal accordingly. It's worth mentioning that you have been explicitly warned before by other people in phabricator and you can use these as concrete violations of CoC. Ladsgroup (talk) 09:52, 19 May 2020 (UTC)

Hello, given that you still have been unconstructive in your interactions with the editing team even after this warning, We have no choice but to expand this ban to interacting with editing team in all technical spaces (including but not limited to mediawiki.org, IRC, and so on) for the next three months. Keep in mind that this can expand even further if you continue this type of conduct. I highly recommand you to read CoC and reflect on your behaviour, we all are trying to contribute to the movement and like Wikipedia, assume good faith. Thanks. Ladsgroup (talk) 07:20, 21 May 2020 (UTC)

Ladsgroup could you clarify where/what you are referring to as unconstructive? Alsee (talk) 19:45, 21 May 2020 (UTC)

As stated above, you can get into the process of a formal CoC appeal to know more of what led to this decision and probably we would be able to share material within the guidelines Ladsgroup (talk) 10:26, 30 May 2020 (UTC)

flowlike movement

Hi Alsee

As you know, I am a big supporter of the flowlike movement. However, earlier today I was hit by a deficiency of the Flow software flavor installed on this wiki, and am starting to wonder if I was wrong all along and you were right.

This is what happened: while participating on a talkpage on this wiki, trying to iron out difficulties, and offering feedback to a wmf employee, my last comment vanished into thin air. I had to hunt for it, and with some help discovered that my comment was deleted by a local admin. Yes, it was deleted not merely reverted with the label off-topic and needlessly insulting, which I vehemently object to. I re-posted an identical message, but this one also disappeared.

Why the WMF decided to expose this community to this piece of software that is clearly inferior to the old-fashioned wiki-talkpages is a mystery to me. It was one thing to participate in an alpha/beta trial on wikiproject breakfast where all participants knew this was a trial of untested software, but to install it on a very busy wmf-site that is trying to conduct serious business, without informing contributors that they are being used as guinea pigs, is a questionable decision.

Your miles may vary? Cheers, Ottawahitech (talk) 23:47, 20 December 2020 (UTC)

I also dislike Flow, but I don't see why it's a bug that posts can be deleted. Your re-post of the same content was deleted by the same admin, with the same edit summary.
This rant appears to be more about overzealous moderation of comments on MediaWiki.org than about problems with the software. * Pppery * _{it has begun} 23:55, 20 December 2020 (UTC)