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.

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.

In T228986#5405995, @Addshore wrote:

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.

In T228986#5408986, @Jakob_WMDE wrote:

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.

In T228986#5405995, @Addshore wrote:

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.

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.

@raja_wmde here the discussion so far.