https://bugzilla.wikimedia.org/show_bug.cgi?id=41338

Nemo <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[email protected]
         Resolution|---                         |WONTFIX

--- Comment #6 from Nemo <[email protected]> ---
(In reply to comment #1)
> Summarizing the two proposals here:
> 
> (In reply to comment #0)
> > The easy way is to disable the edit button for very busy articles.
> > when anyone clicks the big edit button at
> > the top of a busy article render: "Sorry, but this article is currently very
> > busy, so to reduce edit conflicts you can only edit one section at a time.
> > Please pick the section you want to edit", then gave them a choice of 
> > sections.

Looks like an extremely bad idea. We must not add more clutter, we have to make
things work. --> WONTFIX

> The difficult thing is to reduce edit conflicts at newpage patrol.
> > Now the
> > complicated way to reduce edit conflicts here would be to have some logic in
> > the editor that treated paragraphs, categories and templates as independent
> > entities much as it does sections

This is solved by the PageTriage extension.

(In reply to comment #5)
> (In reply to comment #3)
> > I've just had an edit conflict where someone had responded to a different 
> > post
> > in the section, so I'm pretty sure it currently works at section level. If 
> > it
> > differentiates by paragraph then it needs a blank line
> 
> Yes, it needs a blank line. A blank line is the markup for a paragraph in
> wiki
> syntax. And yes, it would be very nice if lines starting with "#", "*" or ":"
> (or space, or... ) would also be paragraphs. 
> 
> That might actually be doable without too much pain, and would probably
> already
> greatly reduce the change of edit conflicts on talk pages. I propose to file
> that as a separate feature request - it's a concrete request and a
> self-contained change, so there's a good chance that it gets implemented
> swiftly.

I agree, someone please define the request exactly and keep bugs specific
(defining the aim and not the proposed solution). We already have bug 13462 and
bug 42053.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to