Page MenuHomePhabricator

Talk with component library internal stakeholders
Closed, ResolvedPublic

Description

There are considerations within the Wikidata Bridge Hike and the Termbox Hike to move previously internal vuejs components to a new public component library and to include them as a dependency via npm.

Communicate with @alaa_wmde and/or @Addshore about the questions (incomplete list):

  • Is this to be considered an official WMDE product, and if so, who owns it in terms of product and strategy? (@Lydia_Pintscher? Lead Devs? UX (@Jan_Dittrich, @Charlie_WMDE)? )
    • Is this subject to the deprecation policy/Stable Interface Policy?
    • What is the process for its documentation for it to be usable by future (3rd party) developers?
    • What is the process for its announcement? ( do we need even one?)
  • How should we approach this?:
    • Is there a hook for gerrit and npm?
    • Should it be implemented similar to wikibase-wdio?
  • How can we setup a process with the still on going Termbox -Hike (@Jakob_WMDE , @Tarrow)?
  • Do we want this shared components approach?

....

This task is strongly connected to T228985

Event Timeline

Michael updated the task description. (Show Details)Jul 25 2019, 1:12 PM
Michael added a subscriber: Jan_Dittrich.
Michael triaged this task as High priority.Jul 25 2019, 1:20 PM

Using something like storybook would probably ease it for PM and UX to join such conversations and it might also be a useful place to store/view component documentation.

Is this subject to the deprecation policy/Stable Interface Policy?

Worth mentioning that the resulting package will be, in contrast to the APIs which stable interface policy notoriously applies to, versioned.

Michael renamed this task from Talk with TechLead to Talk with component library internal stakeholders.Jul 26 2019, 12:53 PM
Michael claimed this task.Jul 31 2019, 2:20 PM
Michael moved this task from To do to Doing on the Wikidata-Bridge-Sprint-3 board.
Restricted Application added a project: User-Michael. · View Herald TranscriptJul 31 2019, 2:20 PM
Jan_Dittrich added a subscriber: Volker_E.EditedAug 1 2019, 9:14 AM

Worth mentioning that the resulting package will be, in contrast to the APIs which stable interface policy notoriously applies to, versioned.

OOUI (@Volker_E) is also versioned.

by future (3rd party) developers

I imagine to create a good 3rd party library to be hard and I currently do not know good usecases for it. So let's proceed with caution there. (For example binding to Typescript might make adaption harder etc.)

What is the process for its announcement? ( do we need even one?)

I think we should have one, since it eases organization, stabilization and accountability.

Is this to be considered an official WMDE product, and if so, who owns it in terms of product and strategy? (@Lydia_Pintscher? Lead Devs? UX (@Jan_Dittrich, @Charlie_WMDE)? )

If this is talking about, is the bridge a product in itself, i would assume yes.
And the owner of the product I would guess is Lydia / whichever PM is leading the work.
Though for this library vs no library task us devs probably have more of a say.

Is this subject to the deprecation policy/Stable Interface Policy?

That depends on exactly what will be changing while moving these internal components to a lib.
As termbox isn't really released yet and neither is bridge we probably need not worry.
Especially as the stable interface policy says:

  • Wikibase JavaScript code is not considered a stable interface.
  • The HTML DOM structure generated by Wikibase is not considered a stable interface.

What is the process for its documentation for it to be usable by future (3rd party) developers?

Do we have 3rd party developers that currently want to use it?
If not I would lean toward not making an official public release yet and instead only having it serve our need which is code reuse between these products.

What is the process for its announcement? ( do we need even one?)

I guess that depends on if we were to make this a real public thing straight away.

How should we approach this?:

Is there a hook for gerrit and npm?
Should it be implemented similar to wikibase-wdio?

It should probably remain consistent with our current other npm libs.
We could probably do with some documentation about how they are handled tbh.

How can we setup a process with the still on going Termbox -Hike (@Jakob_WMDE , @Tarrow)?

I guess that specifically and this ticket in general is something that hike would need to comment on.

Do we want this shared components approach?

Do the benefits outweigh the costs?
What are the costs and benefits?

FWIW I don't think we're at the stage where this is anywhere near stable/interesting enough for the rest of the world to make an announcement.

Is this to be considered an official WMDE product, and if so, who owns it in terms of product and strategy? (@Lydia_Pintscher? Lead Devs? UX (@Jan_Dittrich, @Charlie_WMDE)? )

If this is talking about, is the bridge a product in itself, i would assume yes.
And the owner of the product I would guess is Lydia / whichever PM is leading the work.
Though for this library vs no library task us devs probably have more of a say.

My interpretation is that "this" refers to the component library, not bridge. I'm having trouble seeing the need for product ownership for it. Are we afraid that different hikes using/working on the library will have conflicting ideas as to what the library should contain, or how specific component interfaces should look like? I would hope that our usual code review processes are enough of a solution. I don't see a reason not to treat it like any other internal library for now and let it evolve naturally with as little process as possible. If it becomes a shiny all-purpose component library within a few months, we can always revisit the decision.

Or is this about the resources for initial setup and maintenance that cannot be directly accredited to either of the ongoing hikes, and would need a special "permission"?

How can we setup a process with the still on going Termbox -Hike (@Jakob_WMDE , @Tarrow)?

I guess that specifically and this ticket in general is something that hike would need to comment on.

I like the idea of a shared component library a lot. I'd be happy to help! It makes sense for this to be a shared npm dependency. I don't see a lot of potential for stepping on each others toes since Termbox is finished with user-facing features for its MVP release since last week.

Do we want this shared components approach?

Do the benefits outweigh the costs?
What are the costs and benefits?

There will be some cost of getting it set up initially with a repo, npm package, CI, storybook, and initial release and use in the two code bases. Then there will be maintenance cost in making releases, coordination (review, mainly?) across hikes.
The benefits would be reusing components across features, higher quality components with more eyes on it, components looking the same, not just similar, and changes happening in a central place. Going more into the long-term vision, there would be great benefits in having a large component library serving as a communication device between dev and UX.

My interpretation is that "this" refers to the component library, not bridge. I'm having trouble seeing the need for product ownership for it.

The underlying question was whether we aspire to have at some point a vue-js component library that is in its mission similar to OOUI. Such a thing would clearly need ownership and ideally right from the start.

But based on the comments above, I gather that this is not the idea, but rather to have a low-level way of sharing some internal code between repositories. The third repository is then only a way to facilitate that and not a thing in itself.

What is the process for its documentation for it to be usable by future (3rd party) developers?

Do we have 3rd party developers that currently want to use it?

This is somewhat circular. What 3rd party developer would want to use a library that is not stable? This would be more of a strategy question: "Do we want 3rd party developers to use these components to build their Wikidata/Wikibase related products?"
But, as mentioned above, the answer is apparently "No.". Which is also fine, because it means we can build an internal repository quickly and without having to think too much beyond our immediate use case 👍

Thank you for your feedback 🙂

Are we afraid that different hikes using/working on the library will have conflicting ideas as to what the library should contain,
or how specific component interfaces should look like? I would hope that our usual code review processes are enough of a solution.

I think code review is not a good point for accepting or rejecting components.

  1. I assume the component library should be a joint effort at least of UX and Devs
  2. In code review, the things are already build

There should probably be a way to drafts/suggestions which are reviewed together by dev and UX using a channel which is easy to access and use without specific dev or design skills.

we aspire to have at some point a vue-js component library that is in its mission similar to OOUI. Such a thing would clearly need ownership and ideally right from the start.

I think we need ownership and coordination.
Even if we do not attempt to do something like OOUI. The same structures that would help external people to use it are also useful internally to see what components are there, to negotiate how to progress and to have quality standards for things that go in the library.

Michael removed Michael as the assignee of this task.Aug 27 2019, 12:42 PM
Michael added a subscriber: Michael.

We made this one topic of yesterday's cross-team retrospective.
Realization (how we operate once we know there is something to act on) was mentioned, as well as the perceived need for institutionalized ways of detection of potential synergies between teams (which otherwise would go unnoticed).
It was described that currently the developers of the teams feel that either task is reliant on individual initiative and consequently somewhat left to chance. This is even more true for the topic of ownership and coordination (which would effectively constitute self-entitlement).
Dev team members expressed the wish for more guidance, both by central players and/or an agreed-upon [written] strategy.
Central players expressed a word of warning from premature optimization. They also questioned the feasibility of a centralized approach to addressing these challenges.

Dev team members concluded with the idea to prepare a more specific list of topics in which guidance is desired in the hope that this can then be better processed.
Additionally the current bridge feature team will proceed with this topic on the grassroots level.

Pablo-WMDE closed this task as Resolved.Aug 28 2019, 5:16 PM
Pablo-WMDE moved this task from Doing to Done on the Wikidata-Bridge-Sprint-4 board.

@raja_wmde here the discussion so far.