hi sweet team,

as previously announced I am creating this ticket to start gathering the questions that we will need to answer to even start. I can imagine questions coming from PM, UX as well as Engineering.

Paralelising getting some of the answers here to other currently ongoing work will avoid big gaps in between projects.

So @jon_amar-WMDE , @kera_wmde , @RickiJay-WMDE , @roti_WMDE , @adee_wmde , @lojo_wmde:

• Can you think of any other open questions?
• Can you think of any users's needs that I may have missed?
• Can you think of anything else that could be relevant for the purpose of this ticket?

Just want to point out at least two other features approaches established from the Wikidata experience:

• gadgets, some of then adds a lot of productivity for the day to day work
• bots, or most precisely, bot tasks, executed by scripts and in some cases doing very important repetitive maintenance tasks

IMHO they should be systematized in WBS. Bots tasks, maybe, managed as executable notebooks (jupyter or similar).

Also, maybe can have sense to use wikibase.world as the features inventory for the suite.

I recognize that this task description is over a year old, so I wonder if some bits of it need improving given it's just landing on a team sprint board.
The things that I notice:

• Since Wikibase Suite users have some very different needs to other Wikibase users, as far as I understand there isn't really a distinction in these user bases now? There are no such things as wikibase users really? Again citing the explanation from a few months ago on Telegram
  P75685 (An Untitled Masterwork)

  1	We think of it like concentric circles:
  2
  3	inner - suite is what the suite team ships. i.e. docker based solutions to easily deploy wikibase (our images and wb deploy)
  4
  5	middle - suite is wikibase self hosting. all users trying to self host wikibase are our users. we cant necessarily serve all of them with equal focus because we have limited resources and try to make investments that benefit as large a community as possible. or to invest in building bridges for under represented communities to join in and make it their own.
  6
  7	outer - suite is part of an ecosystem build on wikibase, focused on organising semantic, linked open data. including cloud and wikidata.

• Our current system to add functionalities to our wikibase suite bundle is based on the mediawiki extension mechanism the bundle concept for wikibase suite only exists as part of the wikibase docker images, not other methods of installing wikibase suite. Is this system only meant to target the container images, or rather all suite situations?

Skimming the rest of the content, I find things even more confusing. It sounds like you are trying to reinvent some wheels here.
All parts of the goal except for the mechanism needs to be easily and efficiently improved and maintained by the in-house team for example are already covered mostly or partly by extensions?

As with other tickets though, perhaps this is just the case of things being called weird names? what does Wikibase Suite Bundle mean in this case?

In T360206#10682397, @Olea wrote:

Thanks for the comment @Olea, and some additional thoughts from me here...

Just want to point out at least two other features approaches established from the Wikidata experience:

• gadgets, some of then adds a lot of productivity for the day to day work

The flexibility that gadgets allow for wiki users to make their own custom scripts to hack the software is great, and it's agreat proving ground for functionality.
Some examples on wikidata would be the labels lister that allows actually seeing all lables on an item or property (which the UI doesnt / didnt out of the box), and allows editing them all, or the merge gadget, that actually exposes a way to merge items from the item page itself.
Really though, once proven, IMO there things should not live on as gadgets, they should be included within the software for every to take advantage of in a consistent and expected way supported by a wikibase team.

• bots, or most precisely, bot tasks, executed by scripts and in some cases doing very important repetitive maintenance tasks

IMHO they should be systematized in WBS. Bots tasks, maybe, managed as executable notebooks (jupyter or similar).

This again raises the question for me as to what are we talking about here? As this starts to lean more toward talking about wikibase deploy again?
Crossing over to what I said about gadgets, there are some bots of wikidata that coyuld easily be argued should be included as a feature in wikibase, but again in those cases I wouldnt expect this to be done via a jupyter notebook, or some arbitrary code somewhere, but rather as a product feature.
A good example of this might be the bot that renamed properties, or bots that create tables from sparql queries perhaps?

In T360206#10779344, @Addshore wrote:

Thanks for the comment @Olea, and some additional thoughts from me here...

Just want to point out at least two other features approaches established from the Wikidata experience:

• gadgets, some of then adds a lot of productivity for the day to day work

The flexibility that gadgets allow for wiki users to make their own custom scripts to hack the software is great, and it's agreat proving ground for functionality.
Some examples on wikidata would be the labels lister that allows actually seeing all lables on an item or property (which the UI doesnt / didnt out of the box), and allows editing them all, or the merge gadget, that actually exposes a way to merge items from the item page itself.
Really though, once proven, IMO there things should not live on as gadgets, they should be included within the software for every to take advantage of in a consistent and expected way supported by a wikibase team.

I think I can agree with this. My starting point is just a factual view of the current practices. This is why I want to populate an artifacts inventory (T391821) to first be aware of what is being used and next to decide how to support this features.

• bots, or most precisely, bot tasks, executed by scripts and in some cases doing very important repetitive maintenance tasks

IMHO they should be systematized in WBS. Bots tasks, maybe, managed as executable notebooks (jupyter or similar).

This again raises the question for me as to what are we talking about here? As this starts to lean more toward talking about wikibase deploy again?

Yes. As I understand by the context this ticket is related to the WBS deploy.

Crossing over to what I said about gadgets, there are some bots of wikidata that coyuld easily be argued should be included as a feature in wikibase, but again in those cases I wouldnt expect this to be done via a jupyter notebook, or some arbitrary code somewhere, but rather as a product feature.
A good example of this might be the bot that renamed properties, or bots that create tables from sparql queries perhaps?

Agree. When I talk of Jupyter is as a product feature implemented in the Deploy orchestration, as is the only immediate thing I'm able to contribute.