UPDATE

User story

• As a WF power user, I need a way to review and approve an implementation for a function definition
• As a WF power user, I need a way to disable an active implementation that is performing poorly

Product solution

• We allow the user to review and approve an implementation or disable an active implementation, from the function definition page

Design brief for view function

@DVrandecic I have questions about the following requirements:

A function page offers a list of all its implementations and testers, and whether they are connected or not.

• Do testers also need to be connected to a function? Or are they connected the implementation? And where do you envision the user connecting/disconnecting testers?

A function page shows for each combination of implementation and tester whether that tester passed for that implementation or not.

• IIUC the user needs a way to see which tests an implementation has passed and which it has failed?

A function page shows its ZID.

• We've discussed this before but it's been a while so just to refresh my memory please -- which user will find seeing the ZID valuable and why?

Hi @aishwaryavardhana , here we go:

• Do testers also need to be connected to a function? Or are they connected the implementation? And where do you envision the user connecting/disconnecting testers?

Testers are connected to the function. They are not connected directly to an implementation. Testers should be connected and disconnected on the function (definition) page, just like implementations. That should be entirely parallel.

• IIUC the user needs a way to see which tests an implementation has passed and which it has failed?

Yes, I think that would be great. We currently have that table with implementations on one side and testers on the other side, and then each cell saying whether it passed or not. Something like that would be my favorite. You had the text "6 out of 8 tests passed" on the implementations, which is also sufficient; but it would be nice to have something like the table somewhere.

• which user will find seeing the ZID valuable and why?

ZIDs are stable identifiers. Names can change. If a user wants to be sure they refer to the same function, even across languages, the ZID is the only way. The URL is based on the ZID. Plenty of external systems that will use Wikifunctions will rely on the ZIDs. If a user wants to use these functions, and if we want to make Wikifunctions easily extensible, people will rely on ZIDs. For example, if a user, particularly in a low resource language, wants to understand how another wiki, possibly also low resource, is using a function, they would rely on the ZID as the one stable identifier. If a paper or external publication refers to a function, they will do so via the ZID. The name does not provide identity, the ZID does. In order to not rely on a default fallback language, we use ZIDs. It should be easy to copy and paste a ZID from a function page (in fact, from every object page).

This is helpful thank you!

re: Testers

• Is connecting/disconnecting testers only for users with special permissions? Are the folks who have these rights the exact same group who can also connect/disconnect implementations?
• Since we want users to connect/disconnect testers from the FD page, I'm curious what information the user will need on the FD page to make a good decision? In your mind, what is the ideal process for connecting a tester?
• I'm assuming once a tester is connected, all connected implementations pass it? Is that correct?

re: ZIDS

• Do we expect function names to change frequently within a language? Or is the bigger issue that names change across languages? And what if editing a function name (e.g. Changing 'Negate' to 'Inverse') required special permissions?
• Would you mind writing out the journey of a low resource language user using the ZID to accomplish a goal? It can be 2 sentences!

Testers

• Is connecting/disconnecting testers only for users with special permissions? Are the folks who have these rights the exact same group who can also connect/disconnect implementations?

Yes and yes

• Since we want users to connect/disconnect testers from the FD page, I'm curious what information the user will need on the FD page to make a good decision? In your mind, what is the ideal process for connecting a tester?

It is pretty much the same as with implementations. They might want to check the tester itself to see what is being tested. They might need community discussion and permission to add / enable / connect / approve a tester. They might be interested in how the implementations are doing with regards to this tester.

• I'm assuming once a tester is connected, all connected implementations pass it? Is that correct?

No, that is not necessary the case. All connected implementations *should* pass it, but there might be numerous situations where this is not the case (examples: the community decides that it is OK to have a test that not all implementations pass, or the backend is flaky and fails a test it should pass, or we cannot run a certain implementation for some reason, etc.). It is up to the community to come up with the rules of which functions and which testers are connected and why.

ZIDs

• Do we expect function names to change frequently within a language?

I don't know - what's frequently? It certainly something I see happening, but I don't know how often. This is particularly true for lower resource languages, where the technological terminology for software hasn't had the chance to develop and mature yet.

• Or is the bigger issue that names change across languages?

Not sure what that means.

• And what if editing a function name (e.g. Changing 'Negate' to 'Inverse') required special permissions?

Preferably not. We want to make it easy for the community to find the best names for a function, and particularly in lower resourced languages, where such special rights could easily lead to a small cabal controlling the terminology in a specific language without oversight otherwise.

If the community eventually requests the feature to make editing a name a special right, we can reconsider. But until then, let's go for the wiki way.

One addition to the requirements:

We currently have

• A function page shows for each combination of implementation and tester whether that tester passed for that implementation or not.

In addition:

• For each combination, I can request more metadata about it

I edited that to the requirements.

@DVrandecic Would you mind adding a user story for that feature?

Who is the user? Why do they need the metadata? What kind of metadata might they access for a given implementation/tester combination?
Thank you!

User story: As a curious user, I would like to know why a certain test failed, or how long a certain test took.

We haven't decided yet on the exact metadata (that will come in the next phase, some discussion is on T282164 ).

In the current system, you can click / tap on the test run (the PASS or FAIL) and then it shows you the metadata below. See screenshot. That is super useful! (Particularly for failed tests)

Design brief completed and signed off