Topic on Talk:Talk pages project/Replying/Flow

PPelberg (WMF) (talkcontribs)

What wikitext should the reply tool use for the indentations it will automatically generate? Does the tool use whatever indentation syntax is used on the page the tool is currently being used on? Does it use : in all cases? Something else? If you have thoughts, the team would value your thoughts in this discussion.


---

Context for this question: When bullets are used for indentations (e.g. on ru.wiki), multi-line comments will render on the page as if they are separate comments. This situation can be avoided if contributors manually insert <br> tags as has been done here. Assuming there will be contributors using the reply tool who will not know or think to manually insert <br> tags, what can be done to make sure their multi-line comments are posted to pages in a way that is legible to others?

PPelberg (WMF) (talkcontribs)
Alsee (talkcontribs)

I don't know if I have a good answer, but I hope this is at least somewhat helpful.

My original suggestion was to copy the markup string for each new line, but you raise an important point. That would create a broken result when the last character is * or #.

We normally handle this with human intelligence. It may be challenging to come up with a good automated solution. Using <br> will usually work, but that would become rather annoying when someone tries to include indentation, a bullet list, or a number list, in the middle of their comment.

My tentative suggestion is that when the initial indent string ends in : to copy the indent string for each new line. When that string ends in * or # you'll probably have to use <br> instead. In general the user needs to be able to modify/fix the automated markup.

Whatamidoing (WMF) (talkcontribs)

If memory serves, @Jeblad has spent some time thinking about some of these problems.

Jeblad (talkcontribs)

If a div, or any element that can be set as a block element through the display css property, is injected in a list, then following list items can be rendered as before. If that div is created as wiki markup, then you must keep using the rules for existing markup, otherwise you will run into problems.

In particular, adding smartness by keeping previous indentation are more or less doomed to fail. It creates problem because it breaks the expectation for what the user is supposed to write. Don't change the expectations about existing markup, that will create huge problems. (You are inside a list, and the communities has abused the list metaphor, so the communities should expect it to break.)

There are less problems with adding a tag function, that will wrap up the complete post, no matter if the post has multiple parts. You must armour the content to avoid further parsing of the content. The reason why you must armour the post is that the parser has no idea where the newlines goes, and will try to restart the list. You get the same problem with a table inside a list.

The core problem is that you need to know where the post begins, and where it ends. As long as both beginning and end is within the same block it is quite easy. If it is in two different blocks it is not so easy. Then you must start inspecting previous revision(s), and things start to get ugly really fast. You can backtrack and find the beginning of a post by looking for previous toolbars, signatures, and changes of indentation, but this is error prone.

It is possible to avoid the whole problem by neglecting one of beginning or end, thus you can't properly delimit the post. The best is probably to neglect the beginning, and add a toolbar (thanks·reply-to) at the end. That is you add a toolbar after the signature, and that toolbar has the reply-to link (or button, or whatever you want to use). Note that this function must (or should) be provided the timestamp or a revision id. (Actually it could be done as a signature function, so to add even more functionality.)

You should probably inject the post (no matter how it is formatted) directly after the post where you clicked on the reply-to link, but note that if you use a tag function and track who you reply to it isn't really necessary.

A slightly smart solution could be to add a special character sequence that says “here starts the post” and running all the way up to and including the signature, but then someone insists to add a reply in the middle of someone else's post. That often happen with a multipart post, unless we add code to stop it. If that has a beginning-of-post marker then the text can be parsed recursively. It is although nothing more than a involved tag function with a new syntax, so better avoided, but it is a possibility.

For those situations where you need to make a reply to a faq or similar, there can be a parser function that creates an anonymous reply link. That should be able to take a direction mark that says whether a post is added above or below the parser function. (This parser function can be the same as the one that creates the toolbar for individual posts, you somply does not reply to a single post.)

Note about timestamp in toolbar: The timestamp makes it possible to link to a specific post. Usually the timestamp is good enough, but sometimes you must use the revision id. You could also use timestamp and username (or user id) but that can also fail. I would guess timestamp is good enough for user added posts, and that the system could inject revision ids when it observes collisions.

Jc86035 (talkcontribs)

There's a live test page for the first version of the software at the VisualEditor test wiki. It might help with visualizing how the finished software would actually look and work.

One of the main reasons I suggested making the new markup compatible with list item syntax was to ease the transition between the existing discussion conventions and the new markup. You could perhaps mitigate this by providing a tool/checkbox for users to try to convert old discussions to the new syntax (or by having the software attempt to do this automatically when a new comment is posted in an old discussion), but I don't know if either of these would be disruptive.

Adding the post immediately after the parent comment would probably be unexpected behaviour, since this would reverse the expected sort order of replies (i.e. in the case where there are multiple replies to a single comment, the replies would be ordered in reverse chronological order instead of in chronological order). I think it could make sense to have both a reply button after the comment and a reply button after any existing replies (especially if there are already e.g. 10 or more replies), with both buttons resulting in the addition of the input form in the location where the comment would be posted (i.e. after the existing replies).

Allowing people to "reply" to a parser function would probably be useful, especially where the top comment is typically separated from the rest of the discussion (e.g. deletion discussions).

Would it not be better for the system to consistently inject revision IDs? This could reduce the complexity of using the data on the page (although I imagine it could still be problematic if users copy comments/discussions between different wikis).

Jeblad (talkcontribs)

I followed some of these threads for a short time, so my knowledge of all discussions are only partial.

(Sorry, it is slightly incoherent, it is four in the morning.)

The page you link to gives the usual wikitag soup I really-really dislike. Adding a reply-link and and doing the posting on visual page helps, but keeping the wikitag soup as bad as it is without cleaning up is less so. Given that this is what many advocates (even if it makes me puke – it really does) then really good solutions are lost, it is more a question of what can be salvaged from the chaos.

(rant: The wikisoup creates a master language that rises some editors above the plain readers. The plain readers that don't control the language of the master race will then feel intimidated. It can be said in many ways, but by creating distance between one group and another group we are creating a deep hierarchy. With wikicode we do it with technical means, but the end result is the same – someone will be intimidated.)

There are at least two different types of replies; one on the main thread which I would simply call “reply”, and one on a specific post which I would call “reply-to”. The first one would be the plain anonymous parser function, while the second would have some kind of id. When I was playing around with a gadget to do this I found that the timestamp was usually sufficient. At enwiki you would probably find that this will create ambiguity, so you can instead use username-timestamp for an id. If even that creates ambiguity you can add the revision, like username-timestamp-revision. Fun thing is, if you give an empty id the system might fill in the id to make it sufficient, or you might create something like "my-amazing-idea". I don't know whether it should be an id or a name attribute, that has some implications. It is somewhat easier to use a counter, like VisualEditor does for references, but a situation might emerge where the whole page is archived, and what would the value of counter then be as there are no old values.

For those cases where the reply is a single part it can be inserted as before. If the reply is multipart, or it is a reply to a specific user, then the easiest solution is to wrap it in a tag function (<post>Here goes the post</post>), armour the output, and use the same indentation +1 given the post for the reply. If you don't do that you run into all kinds of problems. If users insists on writing multi part posts manually with all kinds of made up weirdness, then simply avoid doing anything with it. Add some niceties to the tag function like “thank” link, and people will start using it by themselves.

If the reply is on the main thread, ie. created from a “reply” and not any “reply-to”, then add it in whatever indentation +1. This type of post can use the username and timestamp if the post is signed, but those should be normalized. They can be put back in as stylised signatures, but they should be on a format that can be easily parsed. Here you could use magic names as URN, and do some tricks to parse the timestamp as an URN, but some devs insists on removing the magic names. Trying to parse the insane tag soup for signatures as it is now is probably pretty much stupid… Use a parser function for name and timestamp.

In a multipart post with a post tag function add the user name and timestamp as attributes in the head.

I believe replies should be ordered ascending chronological in the main thread, but a reply-to should be descending chronological on the actual post. Now Flow use ascending chronological on reply-to, but this gives the wrong impression. If I do a reply-to on Whatamidoing I will get a post below this one, which is wrong in my opinion. The reason why it is so is said to be enforcing a flow towards a consensus, but quite frankly I doubt that idea work at all. Usually there aren't that many replies to a single post, the most I have seen is a handful.

In my test at the linked page I got a post inserted on a very weird place, and without any way of telling who I responded to. That is really-really weird. If I reply to someone I would expect the reply to be to this person and not some other stranger. This type of reply are often creating harsh disputes on nowiki. “Do you talk to me? I didn't say so and so!”

One way to get a pretty nice and simple solution is to name the person you do a reply to, that is the same that the post tag function will do, but you might do it as {{reply-to:username|timestamp}} or if you insist on adding new wikisyntax @username-timestamp|. The final vbar is modelled after table syntax. Note that it is a bit awkward to reply to two posts at once. This form of lead-in could be given some special formatting, and then strengthen the readers mental model of this is the beginning of the post. A toolbar after the signature will likewise strengthen the readers mental model of this is the end of the post. It is slightly odd that you end with as much wikicode this way as a tag parser function, but users will probably feel it is more “wikiesque”.

If you make it clear who you reply to, you can add posts at the same indentation level. As it is rather important to avoid deep indentations due to readability, it is important to clarify who you reply to.

Now, assume a callback is registered on the block holding reply-to information, and the user hovers on that block, then the linked post can be highlighted with a marker along the edge. This is pretty simple, but you must have the linkage information, that is at least a timestamp. That will make it a lot easier for the reader to figure out who is replying to whom. Just dumping some text on the page, with or without added VE editing help, will not be very useful. That is my main concern with the linked page, it does not enhance readability, it only enhance editability (yummy).

It is likely that users will ask for a parser function like {{reply-to:username|timestamp}} pretty fast if it becomes easy to point to other posts. In this case they will use it inside their reply, and then they will need some easy way to copy-paste such templates. They will probably just copy the reply-to link and try to paste it inside the edit window.

(The gadget I experimented with was motivated on how to do such highlighting with a special link. It is possible to do this to some limited degree with signatures as the only hint of targets, and a callback run at load time. It simply traversed the parents until list items was found and then added formatted ids. When a fragment link hit the post, then it got a green border.)

Another typical copy-paste is inserting text from the replied post. Other systems usually dumps the whole post inside the window at the cursor position, or at the beginning, or at the end. I'm not sure what's best. Perhaps the user should be allowed to drag-n-drop from the page.

I tend to believe there are several filter and sort orders. You should be able to mute some discussions to be able to figure out what goes on in a discussion of special interest. Assume you have some indentation, who has replied to this specific post? That is much harder to do than to describe, and I don't know if it is possible with a free form wikipage.

Lastly; sometimes you need to know whether someone agree or disagree with a statement. It is quite similar to a “thank”, but would log an active yes or no. This is the easy use case. The more difficult use case is quite involved. I started to write a description for User:Jeblad/subjective voting (in lack of a better name) but it is darn hard to get it right.

Last II: A discussion thread should usually start with a well-defined post, and if that is wrapped in a post tag function, the the spawned div could use a class that transforms the following lists so they have lines on the side. Those line will make it easier to visually see who replies to whom, and may make it unnecessary to identify which post you reply to. This seems to work up to some number of indentations, and then it becomes hard to follow. It is especially the long lines that are troublesome when they run off the screen.

It easier for users that writes the replies manually when they don't have to track who they reply to, but it also makes it possible for users that refuses to follow etiquette to seriously mess up the threads. I could give examples, but then I would probably create a similar chaos in this thread. ;)

The fundamental clause is that you have one canonical definition of a thread, and if someone break that it very quickly gets really messy. Ie. someone decides to outdent to margin even if they reply to someone that has indented. In this case the previous replied post must be stated explicitly, but then if someone later will reply to the original post they to must state that explicitly. It is messy.

Last III: I wonder if it should be visually different whether you reply to a post or you discuss a topic. It could be easier if the users clearly discuss a topic on the leftmost branch, and replies to posts on the other branches. That could streamline the flow somewhat, but I don't know how that should be done. It is probably not sufficient to just name the links differently, somehow the users must want to make discussion on topic focused.

Wild idea; What if posts are detached from the left branch after votes. They stay to the left, gets a little greyed, but not on the branch, and people can reply to them. That little gap could be sufficient for people to stay focused on the thread, as they don't want to get sidetracked. A simple vote on whether the posts is helpful, and only helpful posts stay on the branch. Perhaps it works… Could be trolled easily though, so need some limitations.

Jc86035 (talkcontribs)

Adding a reply-link and and doing the posting on visual page helps, but keeping the wikitag soup as bad as it is without cleaning up is less so.

I have assumed that they would want to change the output HTML at some point (i.e. new syntax). However, it does seem logical that for an early beta version with only a few people using it, they might want users to be able to participate in real discussions on live wikis, which would necessitate using the existing list item syntax.

Usually there aren't that many replies to a single post, the most I have seen is a handful.

If you go to w:en:Wikipedia:Village pump (policy) or w:en:Wikipedia:Administrators' noticeboard/Incidents at pretty much any time, there will be several discussions with lots of bullet point replies to a top-level post (typically a proposal or RfC of some sort). This is the norm for most deletion discussions and votes as well. For the biggest discussions there might be hundreds of replies to the parent comment. I have assumed that the new software will typically follow this structuring approach by default (after all, enwiki does form about 30 to 40 percent of the user base), although allowing the comments to be re-sorted (in read mode, not edit mode) seems like a good idea and could prevent usability issues.

Assume you have some indentation, who has replied to this specific post? That is much harder to do than to describe, and I don't know if it is possible with a free form wikipage.

Presumably it would be possible to tell by tracing back from each reply to the previous appropriately nested comment? Nevertheless, I think you could probably do it otherwise by adding metadata to the comment output (e.g. part of the signature, part of the comment wrapper, etc.). If each comment has a unique ID (e.g. the first revision ID, randomly generated ID, ...) then you would be able to generate anchors and so on, which could work even without changing indentation (e.g. if the anchor/metadata are an extension tag within the signature), but this would rely on users choosing to use the extension and/or choosing to add the metadata manually. Unless you're describing another problem entirely.

Jeblad-demo (talkcontribs)

On reply to a single post

You may have many replies from users discussing the main topic (ie. leftmost branch), but there are usually very few that replies to a specific post (ie. branch to the right). The way we discuss now at the wiki projects are a mess, and it is very difficult to figure out who is replying to whom.

On post ids

The ids must be unique for the whole page, not just a section, and as soon as a part of the page is archived it become difficult to figure out what is the correct index. You could use random identifiers, but then you will get collisions. You could use digests from the individual posts, but then random changes could (would) render the digest unusable. The best workaround I know is to use locality sensitive hashing (LSH) but how should a random user be able to create something like that. Everything some user must do manually will create problems.

Jc86035 (talkcontribs)

Even if it's a mess, the main problem I would see with unilaterally changing it is that users would expect the current sorting system to remain in some form, and changing how comments are nested by default would be considered an unnecessary and disruptive change. The WMF developers already tried to change it in Flow. I don't know if they'll want to try to change it again, and there's no one clear or objective "better" method to do it. (There's also no guarantee that changing the nesting structure would make it less confusing to navigate a large discussion.)

Would w:en:universally unique identifiers not be sufficient? Even in a system where collisions would regularly be produced, presumably the system could retain a full index of IDs and force another ID to be generated if a new ID does indeed clash (although I don't know how computationally intensive this would be). If the signature generates the ID then a user commenting manually wouldn't have to worry about it.

Jeblad (talkcontribs)

An UUID is just some way to write a very large number, it does not solve anything by itself. When the number is very large, the chance for a collision gets very small, but it does not go away, and you still must track all numbers you have used so far. It is possible to do tracking in the page-props table, but you should probably create a new table. The right way to do this would be to use globally unique ids, because you don't know where someone might move the thread.

Then you have the problem the user face when (s)he must write that pesky number manually. It is easier to write an identifier consisting of a user name and a timestamp.

Jc86035 (talkcontribs)

If you were to include the unique IDs in the UUID (in addition to random bits), it would probably help to reduce the likelihood of generating collisions. I don't really know how this would work in practice, though.

If the issue is writing the unique ID when making a reply, I've assumed that users would either reply automatically, copy and paste the ID (from elsewhere in the page source) or simply omit the ID altogether. If the reply is located at the correct place on the page then the parent comment can be inferred, so it would presumably only be an issue if the users have broken the formatting.

Jc86035 (talkcontribs)

Interestingly, Flow/Architecture#IDs indicates that SD already uses the UUID approach. Presumably comments are simply infrequent enough that including the date and time is enough to make collisions impossible.

Jeblad (talkcontribs)

As long as you want to reply to an on-page post the problem dwindle down to copy-paste in most cases. The real problem is the entry of the posts' id, because the user has no interest in adding an id to his own post. For others to reply to that post they must know the id.

You might get around the problem with changing the timestamp into a composite date-time-random string. It is somewhat similar to a UUID, they come in several flavors, and this one is human readable. This works on a single page, but if a thread is moved, then it is not necessarily unique. That's why I believe a signature should be a packed user-date-time-random or a user-revision composite string of some kind, and transformed into a more readable form during parsing.

The move of a post will happen as part of the archive process, even if there are no plans for moving threads to other pages.

Whatamidoing (WMF) (talkcontribs)

In re inserting the revision id into the edit, @Catrope tells me that it's "pretty much impossible" and referred me to https://phabricator.wikimedia.org/T14694#177118 and related ancient requests.

Something about needing to re-architect MediaWiki from the ground up, I think it was. It shouldn't take him too long to make the impossible become commonplace, right? ;-)

Jeblad (talkcontribs)

It is right that you can't easily use the revision, but it is possible – it is all about how and when you want to use the revision. The revision can be lazy-updated if necessary, but it can also be injected on save. This although creates unnecessary complex code.

(I guess the discussion arose because I wrote “If even that creates ambiguity you can add the revision, like username-timestamp-revision.” That is somewhat confusing and unnecessary, and I should have left it out.)

Most of the time you just want user and timestamp, and it is good enough, but that is also hard enough because the users are free to chose whatever format they want. (I.e. it would create a fragile system.) If you only have the timestamp, then several users might save within the same timeframe, so you want to add the user, and you want the composite in a form that makes it identifiable. If the user is named then a collision only happen if the user saves several replies in fast succession, we use a one-minute resolution on the shown timestamp, or several replies on the same save operation. Save in fast succession can be solved by increasing the shown time resolution, save within the same save operation can be solved by adding a counter.

A signature can either be created as a tag-function, a parser-function, a special link, or a template. If a template is chosen, then you need to track that, which is a bit pesky. Users don't expect parser-functions, so using that would be bad. I would say it is best to use a tag-function for a signature, but people often seems to dislike tag-functions. It could be best to use a signature-link and add a timestamp. The actual link could call the users chosen signature on render instead of save, thus it would visually be the same as today, but in wikitext it would be different.

Whatamidoing (WMF) (talkcontribs)

> The actual link could call the users chosen signature on render instead of save, thus it would visually be the same as today, but in wikitext it would be different.


I wonder what effect that would have on renamed accounts.

Jeblad (talkcontribs)

Just keep a redirect. The same problem arise, and is solved, at Wikidata.

Whatamidoing (WMF) (talkcontribs)

Then the redirect would automagically show the new name? Most editors would probably appreciate that.

Alsee (talkcontribs)

I think I said this before somewhere else, but it is a very bad idea to replace save-based-signatures with render-based-signatures. Consider this:

  1. Someone sets their signature to something interesting, perhaps impersonating WMF-Legal for example.
  2. They post a message, using that deceptive signature.
  3. They wait for the target person or persons to read the message, with the deceptive signature.
  4. They change their signature back to normal.
  5. They purge the page... the deceptive signature vanishes.
  6. There now is no log and no evidence anywhere of the malicious actions.
Jeblad (talkcontribs)

Logging changed signatures pose no real problem, and should be done anyhow. It is not done now, but that is a failure and not a feature. (Point 1 would show up in the history anyhow, so the point is somewhat moot, but just assume it work for this discussion.)

If anyone insists, then use a user id. It doesn't change much, but you avoid protecting the redirects.

(Note that falsified signatures is a bit more complex, and isn't solved by the present signature. In fact falsified signatures can't be solved at all without somehow wrapping the posted text and adding a real cryptographic signature for the wrapped text. That would make it near impossible for users to add the signature manually in wikitext.)

Whatamidoing (WMF) (talkcontribs)

> That would make it near impossible for users to add the signature manually in wikitext.

Which would be a problem for people sending (current version of) MassMessages, because we don't really want those signed by the bot. (There are solutions and alternatives, such as Extension:Newsletter.)

Jeblad (talkcontribs)

Not sure, but I don't think it would be a problem to sign a message as someone other than the user sending the message. It is a slightly different problem than the plain “reply-to”, but could be done by a tag function (<post>Here goes the post</post>) were a detached signature is added as an attribute. It would create a bit messy wikitext, it would not be easily edited, but it could work. The current version of MassMessages could be slightly changed, and then it would add the detached signature without the user doing any additional editing.

Jeblad (talkcontribs)

Short version:

Make a tag multipart and wrap it around posts with newlines. This tag will be generally useful, for example for tables inside lists. The lists will only see a single blob, and there are no newlines to mess it up.

Hover for replies: Traverse upwards from block with timestamp until nearest list, and then go up to sibling item. This will be the containing list item for the reply unless someone try to make a mess.

Hover for topics: Parent of list is mw-content, only highlight item.

Hover effects can be done with selectors in CSS, possibly with a single line representing a branch.

Add ids (username-timestamp) to posts so they can be highlighted with a link. This should only higlight a post, not the replies.

Make it possible to copy-paste a reply-to link.

Jc86035 (talkcontribs)

I've explained possibly more of my reasoning than might be necessary, as I don't really know how specific I need to be and what issues I can refer to without explaining them. You might want to read the last parts of the comment first.

I think another common formatting for multiline bullet point comments is to follow * with : (obviously incorrect but renders passably). It's not clear to me what the semantically correct syntax for multiline comments would be (<br> is not ideal, and obviously neither are list items). I believe it would be correct to use <p> to separate each paragraph, but in practice this is very rarely done; I have done this, but only when writing a level 1 * comment. (Within this comment, "level n comment" refers to a comment with n indentation levels; a level 0 comment would usually be the first comment in a thread.) Because the conventions themselves are semantically incorrect, users who actually try to write semantically correct comments are by definition not following said conventions.

It might be preferable to introduce an entirely new syntax for comments written with the new interface while still allowing users to write comments with the old syntax, although how this would work in practice would likely be mostly dependent on the costs and constraints of building a more complex system than would be functionally necessary. (This would make it the software's task to format those comments in a semantically correct way.) It's not clear to me if this is actually going to happen, but I think having new syntax would be a prerequisite of allowing users to make multiline comments, since it would probably reduce the technical complexity of saving multiline comments while still allowing them to be edited (and without discarding the original input). (phab:T230683 and phab:T230658 seem to be the main related tasks, although only the latter is currently under the OWC2020 umbrella.)

For the versions of the software before any new syntax is introduced (if any), I think it could be appropriate to use : automatically; even considering the wide variations in how contributors use indents, "use : in most discussions" is a fairly widely-followed convention that has been the norm since about 2002. However, if replying to a level 0 comment, I would follow whatever list item syntax has been used for the last level 1 comment. (Enterprisey's reply-link would be a good model for this sort of approach.) This won't be perfect – in some discussions there may not even be any machine-readable indication that the software is supposed to indent the first reply using * – but I think it should work in most cases. If this were to be kept around indefinitely, then it would probably be necessary to introduce a better guessing mechanism (e.g. partly based on whether the page title matches a community-defined list of title formats). For multiline comments, I would probably have the software insert <p> for all multiline comments (in spite of this not being a particularly common convention), since this would be semantically appropriate and would be appropriate for all list types, but contributors could potentially dislike this behaviour. (I imagine that it would be understandable while the software is in beta.)

This approach would still result in some broken list formatting; for example, although my understanding is that * should only be used for level 1 comments, some experienced users tend to use it in other places, and some experienced users will indent with :* or :: following a level 1 * instead of using the correct *:. (I would argue that ** would also be incorrect, but some might disagree.) MediaWiki discussion markup usage is in this way similar to natural language, in that the grammatical conventions can easily be ignored, can change over time and can vary between communities. Because of this, I think it would probably be futile to try to make the software produce list item syntax, or at least it likely would be without changing the behaviour of the existing syntax on discussion pages. (I also suggested in phase 1 that an extension tag or some other marker/syntax could be used to indicate the discussion type, similar to the meaning expressed by the usage difference between :, * and #; clearly defining this sort of difference would presumably be an improvement over not doing so, and this and other software changes could potentially enable other feature possibilities like CSS customizations for different discussion types and semi-structured polls.)

Perhaps it would be a foregone conclusion that versions of the software published after the introduction of new syntax should always output the new syntax, even if the new syntax can be mixed with list item syntax. This could potentially make it difficult for users using the older editors to make comments, so it could be beneficial to keep the new syntax at least somewhat similar to the current syntax. Obviously, what the syntax would actually look like is still up in the air, but presumably it would minimally be able to handle multiline comments and most/all current elements of wikitext formatting.

As a side note, it may be impossible to surface the software in some cases if it can only be accessed from the "reply" button (particularly if the location of the button is entirely dependent on the location of the comment being replied to). For example, in an RfA support or oppose section, there is no level 0 comment to reply to, so the user will be unable to post a vote; additionally, a single reply button would be insufficient to allow the posting of level 1 comments/votes in all of the support, oppose, neutral and discussion subsections. (The same would happen in many RfCs, and possibly AfDs. In extremely long discussions, users also tend to insert level 3 or 4 headers as "arbitrary breaks" so as to be able to more easily navigate through the page, and this could also prevent the interface from being surfaced correctly due to the top-level comment being in a previous subsection.) I don't know if this has been noted as an issue anywhere else, but I've filed a Phabricator task for it.

In conclusion:

  • I think it is almost necessary to introduce new syntax for indentation (and/or to change the behaviour of list item syntax where it is used for indentation in discussions), so that the software's output can be guaranteed to be correct. Although this could seem unnecessarily complicated, a number of factors – such as the lack of multiline list item syntax, the semantic incorrectness and inaccessibility inherent to the use of definition lists, the inconsistencies in discussion syntax conventions between and even within wiki communities, and the frequent misuse of list item syntax by many contributors – make this complexity justifiable. (In pre-release versions of the software, I think it would be acceptable to temporarily use the existing list item syntax for indentation.)
  • I think the features possible within the current discussion conventions should nevertheless be retained as fully as is practical within the new software and syntax, primarily to avoid reducing contributors' ability to communicate with each other, but also to preserve some flexibility in structure and formatting that might otherwise be lost. This includes (but is not limited to) multiline comments, wikitext formatting, structural flexibility, and the meaning expressed by the differences between the list types used for indentation. I think it would also be beneficial for those features to be expanded, even if they aren't directly related to the main goals of the talk pages project.
  • For any versions of the software which automatically indent using list item syntax, I would prefer a <p>-based approach to multiline comments. However, I think it would be preferable to disable this behaviour before the software is enabled by default.
  • I think users who are unable to (or choose not to) use the new software should ideally still be able to participate in discussions without significant difficulty, so the new syntax should be intuitive and/or similar to current list item syntax.
  • I think it would be premature to widely deploy the software before new syntax is ready (and/or the parsing of list item syntax on discussion pages is changed). Introducing relevant syntax changes first could make it easier for the software to work well regardless of differences between wikis' discussion formatting conventions, and could potentially reduce the development work needed to make early versions of the software work without said syntax changes.
TheDJ (talkcontribs)

If not as supported (simple : indenting), give up and throw people into old style section editing for an initial version, until you get a syntax defined. It's the easiest solution.

Jc86035 (talkcontribs)

+1, initially using the source editor as a fallback would clearly be a lot more feasible than handling lots of edge cases.

Reply to "Indentation syntax"