swalling wrote on 2014-04-18 00:35:52 (UTC)

I have never understood the purpose of the see also field. If it's a dependency, make it a dependency. If not, then just link to the other issue in the description.

Nemo_bis wrote on 2014-04-18 06:47:15 (UTC)

Steven, good thing we have docs. ;) https://www.mediawiki.org/wiki/Bugzilla/Fields#See_Also

aklapper wrote on 2014-04-18 09:21:19 (UTC)

There's only a need for this if people prefer to have a pre-defined field for $stuff ("minimalistic interface vs. categorize everything", anyone?).
Phab docs say "Custom fields can appear in many interfaces and support search" as Quim already wrote.
I wonder if we can search for e.g. "non empty field" in Phab's search.

In any case: Nemo: If comment freeform text is not sufficient for you, please explain your usecase - seeing a ticket marked as blocked by a dependency that's outside of "our" system? If so, just for the records, that wasn't/isn't supported by Bugzilla either so far...

Nemo_bis wrote on 2014-04-18 09:30:00 (UTC)

Clarified comment 0. I really mean a "see also" https://www.mediawiki.org/wiki/Bugzilla/Fields#See_Also

aklapper wrote on 2014-04-18 10:21:42 (UTC)

But what's the actual advantage and usecase for a "See Also" field compared to freetext comment?

"It looks nice up there and somebody could fill it with something" certainly isn't it. :)

Nemo_bis wrote on 2014-04-18 10:28:01 (UTC)

Comments are messy. They are not metadata. People don't read comments, especially on long bugs, and it's especially on long bugs that you need the see alsos for people to immediately get focused.

aklapper wrote on 2014-04-18 10:44:26 (UTC)

But what do you actually use the metadata for, and how often? Metadata for the sake of having metadata isn't what we want, and I see a trade-off between having lots of metadata fields (Bugzilla) and a slick interface which lets your eye quickly gather the most important info.

If I get it right, I could also argument for a feature "vote relevant comments up so they are displayed on top" instead of "create numerous fields on top that could hold some stuff that could be considered metadata"? :)

Nemo_bis wrote on 2014-04-18 13:17:57 (UTC)

Bugs or tasks rarely have clear boundaries. Defining what's within the scope of a bug/task and what's outside is probably the most important goal and that's why "see also" is one of the most important metadata fields. A correct see also can save dozens of misled comments in an already-messy bug report.

Of course here we can edit the description, so the alternative would be to start adding see alsos with some sort of template by collectively editing the description, and refactoring redundant comments by removing/summarising/moving them to other tasks. This is so much like UseModWiki though, I guess we'll also start adding CamelCase tags like CategoryFirefox and the like. :) Hey, sure, there were benefits too in our pre-2002 syntax.

qgil wrote on 2014-04-18 14:00:02 (UTC)

In any case, if we want to have a "See also", Phabricator supports it. Setting priority Low, since there are many other topics that deserve higher attention at this point of the RfC.

jdforrester wrote on 2014-05-10 15:10:56 (UTC)

The proposal at the Zürich Hackathon was that we should add a "See Also" field for now, porting Bugzilla's content to that field in the ETL; later we may choose to use something else.

Does this make sense?

qgil wrote on 2014-05-10 23:21:56 (UTC)

Er... was this the proposal? Good that we have a video (that now at 1:14am I'm not going to watch) but we also said that we have now tasks that can be edited, and the current "see also" could be rendered in the description.

One important detail: in Bugzilla "See also" is a bidirectional property, if you point from one bug to another, there will be a complementary link back added automatically to the other report. Phabricator doesn't do this today. In my opinion, if we want to keep the Bugzilla feature then we need to ask for it as it works in Bugzilla. Otherwise our users will be licitly confused.

Therefore, the only consistent options are either to request the feature upstream and make it a blocker of Day 1, or forget about it before the migration and render the current "See also" links in Bugzilla as regular links in the task descriptions.

jdforrester wrote on 2014-05-11 08:18:37 (UTC)

forget about it before the migration and render the current "See also" links in Bugzilla as regular links in the task descriptions.

I'm content with that outcome too.

aklapper wrote on 2014-05-12 09:37:59 (UTC)

IMHO when migrating data from Bugzilla it feels sufficient to add the "See Also" links to the initial comment of a Maniphest task, and for the future recommend to add upstream links in the initial comment of a Maniphest task.

aklapper wrote on 2014-05-23 07:03:04 (UTC)

I propose removing this from blocking the project "Wikimedia Phabricator Day 1" and WONTFIXing it.

Reasons:

• When we import tickets from Bugzilla, it is sufficient to have the initial description of a Maniphest task include links to related tickets. This provides sufficient visibility for human readers. Furthermore, I've seen numerous comments in Bugzilla of developers who missed links in the "See Also" area in the upper corner. This might be just an issue with the location in Bugzilla, but if it should be more visible and central that would be the initial description in Maniphest.
• When it comes to machines (and the clash of the "give me one free text field to dump everything into" vs. "give me separate fields for separate information" paradigms), I really cannot come up with a good usecase in Bugzilla to *query* tickets for a non-empty "See Also" field that would require the field to specifically exist with its dedicated purpose.

If there is a good usecase that I am not aware, please share it here, otherwise this ticket will get closed as WONTFIX soon.

(Sorry for duplicated previous comments.)

qgil wrote on 2014-05-29 08:18:55 (UTC)

+1 with the conclusion, but I would keep this task as blocker of Day 1, only resolved as Wontfix. This is not to give the idea that the conclusion is "Wontfix for Day 1, but maybe later", or something,

(Sorry for duplicated previous comments.)

You can remove them, at least the content.

aklapper wrote on 2014-06-05 14:19:40 (UTC)

aklapper wrote on 2014-06-05 14:19:47 (UTC)

aklapper wrote on 2014-06-06 20:06:48 (UTC)

So I'll be bold and WONTFIX this, given that I don't see convincing reasons to have a dedicated (machine-readbale) field for this. Things can go into the initial description.

If you disagree with my judgement, please explain and reopen this ticket. Thanks!

Nemo_bis wrote on 2014-06-15 10:56:12 (UTC)

So I'll be bold and WONTFIX this, given that I don't see convincing reasons to have a dedicated (machine-readbale) field for this.

It's not about machines, it's about humans...

Things can go into the initial description.

Will they? For instance on T58 I couldn't figure out there was an upstream report until I read the last comments and guessed the link was somewhere in between, among the collapsed comments (not even ctrl-f over comments would help).

One important detail: in Bugzilla "See also" is a bidirectional property, if you point from one bug to another, there will be a complementary link back added automatically to the other report.

Yes, that was a fantastic enhancement in recent versions of bugzilla, which increased the discoverability of similar reports a lot. A great help for users wandering around confused. I don't see anyone going to edit two task descriptions for each connection, as most people used not to when the field was not bidirectional.

aklapper wrote on 2014-06-15 12:25:05 (UTC)

It's not about machines, it's about humans...

Humans can read and edit an initial description.

Will they?

Don't know, humans are individuals, but we can provide guidelines and best practices. Many people don't read 150 comments in a Bugzilla report either and miss important information, so it's rather unrelated to the tool itself.

I've also seen a few comments by not-every-day Bugzilla users that they didn't see the links in "See Also".

in Bugzilla "See also" is a bidirectional property

That's certainly one thing I'd miss and we'd have more work in Phabricator, yeah.

aklapper wrote on 2014-08-18 21:08:21 (UTC)

[Fixing task status again which got munged when renaming according to T359.]

importing issue status