Re: [Wikitech-l] Feature request.
On Wed Nov 19 2014 at 3:50:02 PM Nathan wrote: > Why not just interleave or nest the conflicted edit in the history of the > page? So if you are editing revision 1, and conflict with someone elses > revision 2, save your revision as 2 and the next person's revision as 3? > There's some ugliness in the revision history to resolve (like timestamps), > and potentially other ways it could be done, but I see no reason not to > slot the conflicted edit into the history while prompting the user to merge > into a current revision. > > Except since rev_id auto-increments you'd end up with an out-of-place rev_id in the history. In your example you'd end up with something like: [[Page]] history: - Latest rev by Joe (rev_id 2) - Previous rev by Jane (rev_id 3) <- This was the edit conflict, inserted after the fact - First rev by Jim (rev_id 1) <- This one was the one Jane and Joe both began editing from -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Mon, Nov 17, 2014 at 1:56 PM, James Forrester wrote: > On 16 November 2014 14:36, Pine W wrote: > > > James: would it be possible to automatically save the text of a page to a > > user's sandbox when they encounter an edit conflict? This would overwrite > > the content of the sandbox, but that could be reverted using the normal > > history page for the sandbox. > > > > Hmm. Publishing content without the user clicking the "Save page" button a > second time feels very icky. Also, would we need to go around and > auto-delete these for users once the edit conflict was fixed? This doesn't > sound like a perfect solution. There's also the issue with "the user's > sandbox" not existing as an actual thing, just a hack that a couple of > wikis have invented… > > Maybe we should make the (read only) "your content" box more prominent, > appearing before the "current content" one? Not sure this would help more > than it would hinder everyone for the order to be reversed. > > J. > -- > > Why not just interleave or nest the conflicted edit in the history of the page? So if you are editing revision 1, and conflict with someone elses revision 2, save your revision as 2 and the next person's revision as 3? There's some ugliness in the revision history to resolve (like timestamps), and potentially other ways it could be done, but I see no reason not to slot the conflicted edit into the history while prompting the user to merge into a current revision. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
On Thu, 20 Nov 2014, at 10:22, Bjoern Hoehrmann wrote:
> * Zack Weinberg wrote:
> >On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk wrote:
> >> It sounds like the data loss here was purely due to user error, David.
> >
> >Don't blame the victim.
> >
> >> Maybe we could allow saving things to a given subpage of their user page
> >
> >Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of
> >the "wipes out what was there already" problem.
>
> I would rather expect an "autosave" feature to use some local storage
> mechanisms
+1 for that. Unfortunately local storage in modern web browsers behaves
unreliably. Yet instead of acknowledging that improvement and standardizing of
the local storage is long overdue, people develop "native" mobile apps. In my
view your post shows where this approach hits a ceiling (as most desktop users
don't have a "easily install an app" culture or even a package manager, such as
the popular windows platform).
--
Svetlana
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
* Zack Weinberg wrote:
>On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk wrote:
>> It sounds like the data loss here was purely due to user error, David.
>
>Don't blame the victim.
>
>> Maybe we could allow saving things to a given subpage of their user page
>
>Users/{name}/backup/{pagetitle}/{serial number} ? That gets rid of
>the "wipes out what was there already" problem.
I would rather expect an "autosave" feature to use some local storage
mechanisms (to keep incomplete edits confidential and to deal with e.g.
connectivity problems). Making the recovery process discoverable is a
bit difficult, but in any case, wikispace is not a good place to save
such content, even if it's done only for edit conflicts for edits that
have been submitted.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
Available for hire in Berlin (early 2015) · http://www.websitedev.de/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: New in Platform Engineering: James Douglas and Stas Malyshev
Hi everyone, We have two new people starting this week in Platform Engineering. James Douglas James started yesterday as the second member of our newly formed Services group. "Services" in this context are standalone software components that often run on their own machines and have very specific jobs, such as "generate a PDF from this article". Much of our infrastructure isn't that specific, so you'll hear us talking a lot over the next year about moving toward "Service Oriented Architecture", which basically means taking our general purpose software and breaking it up into more focused components. James working closely with Gabriel Wicke on bringing new services online, such as RESTbase[1]. James comes to us from Versal, an organization he co-founded, and where he was responsible for building out a Scala-based online education platform. He lives here in San Francisco, and he'll be sitting beside Gabriel on the south end of 3. You can find a wealth of writings about his work with Scala as well as other software development topics on James' personal website[2]. Stas Malyshev Stas joins us from SugarCRM, where he was Software Architect since 2010. Prior to working at Sugar, Stas worked at Zend (makers of PHP), where he was employee #1, and build the first version of their website. In debugging problems on the website, he eventually got slurped into fixing bugs and eventually doing much more with the PHP runtime itself. If you're a php developer (or maybe even if you're not), you should be following Stas's blog[3] where he talks about many issues in PHP development. Stas will be working in the MediaWiki Core team, mostly focused on performance issues (though right now is getting up to speed on the Wikidata Query Service[4], figuring out what we need to do to make it suitable for widespread deployment of WikiGrok[5]). Stas lives in San Jose, and will be working mostly remotely, but will be coming up to the office about once a week. When he's here (like today) he'll be on 3rd floor south. Welcome James and Stas! Rob 1. https://github.com/gwicke/restbase 2. http://earldouglas.com/ 3. http://php100.wordpress.com/ 4. https://wdq.wmflabs.org/ 5. http://www.mediawiki.org/wiki/Extension:MobileFrontend/WikiGrok ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla-Phabricator migration: 21 Nov at 00:30 UTC
We are polishing the last details before starting the Bugzilla migration to Phabricator on 21 November at 00:30 UTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141121T0030 You can find all the details of what will happen next in the timeline at https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla MIGRATION WEEKEND Basically, Bugzilla access will be restricted to read-only, Phabricator will be pulled, and we will start the migration. If all goes well, by Monday 24 Phabricator will be back with about 75k tasks, and Bugzilla will be archived in old-bugzilla.wikimedia.org. During this period, we will redirect users to a page asking them to postpone their bug reporting unless it is so urgent that it cannot wait until Monday. In that case, they can use #wikimedia-bug2phab on IRC and mediawiki.org's Support Desk. If you registered in https://phabricator.wikimedia.org before the migration, your Bugzilla activity will be probably assigned to you by the time you check the site. Otherwise, you will still be able to register and claim your activity, which will be assigned to you within a couple of hours or a couple of days, depending of the queue. KNOWN ISSUES We are confident about the stability of Phabricator and also about the reliability of the migration process. However, there are several known issues related with data and features that will be missing next Monday. We cannot assign to Phabricator tasks the same number as their Bugzilla equivalents. Instead, automatic redirects will link old Bugzilla URLs with their corresponding new Phabricator tasks. phabricator.wikimedia.org has already >1300 tasks with numbers taken. The migration needs to be done by batches of bugs instead of sequentially, which makes the mapping of numbers more complicated. Still, smaller numbers will correspond to older bugs, and we will do our best during the weekend to improve the sorting. Votes and saved searches cannot be migrated. Users willing to have their equivalent in Phabricator (tokens a new saved searches) will be able to access their accounts in old-bugzilla. A feature that we expect to be missed is suggestions for duplicates when creating a new task. Even if Phabricator's search is powered by Elasticsearch, we feel like it needs some fine-tuning to get to Bugzilla's efficiency. Advanced Bugzilla users will also find that some actions take more clicks (assigning blocker/blocking tasks, for instance). In general, most fluent Bugzilla users new to Phabricator will need a few days to get used to how things work in Phabricator. There is a complete list of known issues at https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Known_issues -- and we will keep working on them after next Monday. IMPROVEMENTS We expect that the improvements will make the change worth right after the migration, of course. A simpler and cleaner UI that works on mobile, Wikimedia SUL, bugs and features living together, ability to associate tasks to several projects, workboards, and many more features are waiting for you! :) -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] VisualEditor office hour for November and January
Hi everybody, and apologies for cross-posting. This is a reminder that the VE office hour for this month is happening *today in a few hours, at 1600 UTC* [0]. James Forrester will be available to answer any questions about recent improvements and to provide details about ongoing and planned work. It is also a pleasant occasion to share your experience; the team always looks forward to hearing from you. I'd also like to inform you that we are not going to have an office hour next month, so the next appointment to discuss VE is in *January, Wednesday 7th at 2200 UTC* [1]. Previous logs and other information, including how to participate, can be found at Meta [2]. Hope to see you in #wikimedia-office in a while. Best, Elitre (WMF) https://www.mediawiki.org/wiki/Community_Engagement_(Product) [0] http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=00&sec=0&day=19&month=11&year=2014 [1] http://www.timeanddate.com/worldclock/fixedtime.html?hour=22&min=00&sec=0&day=07&month=01&year=2015 [2] https://meta.wikimedia.org/wiki/IRC_office_hours ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
