[Dev] Smart Search: Index custom fields about j4.docs

[ceford]

Thanks for the clarification. It seems we can do everything here in GitHub and do not need Mattermost Boards. Is that right?

[carlitorweb]

Yes, that is correct

[ceford]

When an issue is opened I think it is important to look at the PR to see which documentation needs updating. It could be Help page, a User Tutorial page or a Developer Information page. In this case the PR says:

## Documentation Changes Required

The documentation needs to be amended to contain how to implement this feature for third party finder plugins.

That suggests Developer Docs. If such a document exists the link should be to it. Copying this to a discussion.

[max123kl]

If such a document exists the link should be to it. Copying this to a discussion.

If there is no page, it needs to be created.
I prefer to stay here with comments. So when moving to discussions, I can see no advantage.

[carlitorweb]

@max123kl Just for you kown. The projects cards can be trigger automatly when a pull-request is marked with a tag. So, when in joomla repo, a pull request is marked with the Documentation needed tag or other tag we plan to use it, you will have a card created, where you can add all this checkboxs or related things right there. That is why we no need create or use Issues for this.

[max123kl]

@carlitorweb Yes, there is no must. In the JGerman repo, the workflow is set up in such a way that an issue is always started first and then, when all the questions about what needs to be done have been clarified, a PR with the same name is started. The files are then merged into the repo as soon as the PR has been published.

At first glance, the two-stage working method seems awkward. However, it helps to keep the preceding discussions away from the actual PR and makes the PR easier to follow.

I have learned to like this workflow very comfortable in the meantime.

[ceford]

@max123kl Just for you kown. The projects cards can be trigger automatly when a pull-request is marked with a tag. So, when in joomla repo, a pull request is marked with the Documentation needed tag or other tag we plan to use it, you will have a card created, where you can add all this checkboxs or related things right there. That is why we no need create or use Issues for this.

@carlitorweb Can you clarify: where is this card created?

[carlitorweb]

@ceford unfortunatelly, these cards are created inside Projects tab https://docs.github.com/en/issues/planning-and-tracking-with-projects

@max123kl you can create the project, follow here: https://docs.github.com/en/issues/planning-and-tracking-with-projects/creating-projects/creating-a-project#creating-a-user-project

[ceford]

I followed the Tasks to be done link but could not figure out how to do anything there. Is that just for information?

Assignment to me: where does that appear? Other than above.

[max123kl]

@ceford you should fork this repo and then, as described in Contributing

• first, create a new branch
• make your changes there (e.g. create a new file/folder)
• start a PR
• when all details have been clarified, it will be merged.
• Finally, wait for the contribution to be published in the wiki/dev manual.

We can collect such basic questions in Wiki tab here and build up something like a FAQ

[Hackwar]

Right now there is no documentation in the new dev manual for smart search/finder plugins and this basically has to be all done from scratch.

Looking at this whole idea in general, I would expect this to be done with several branches in sync with the CMS branches and versions. The current version is the active branch and all changes to one version are only merged into that versions branch. When a new minor or major version is released, the active branch is switched to that versions branch and that switches the generated output on the website. Maybe a bot could also help keeping this in sync. When a CMS PR is closed, its documentation PR is also automatically closed, likewise when a CMS PR is merged, its documentation counterpart would be merged. And when a CMS PR is marked as needing documentation, it would add that as a condition to be merged to the CMS PR and when the accompanying documentation PR is ready and reviewed, the bot could checkmark that in the CMS PR. That would help keeping both in step.

[ceford]

@ceford you should fork this repo and then, as described in Contributing

* first, create a new branch

* make your changes there (e.g. create a new file/folder)

* start a PR

* when all details have been clarified, it will be merged.

* Finally, wait for the contribution to be published in the wiki/dev manual.

We can collect such basic questions in Wiki tab here and build up something like a FAQ

The Contributing link has no content!

However, I have completed steps 1, 2 an 3. I have left you to do the merge step. Should Approval be a separate step in the process?

Doing all of this has made me think again about How to Contribute. This is going off-topic again!

[max123kl]

Sorry https://github.com/max123kl/J4.docs/blob/main/CONTRIBUTING.md

[ceford]

Right now there is no documentation in the new dev manual for smart search/finder plugins and this basically has to be all done from scratch.

There is this: https://docs.joomla.org/Creating_a_Smart_Search_plug-in - it just needs markdown conversion

[max123kl]

You see, I started a PR on this issue and marked it as draft. So we can work on this till satisfied.
Further comments on what to alter should be done there

[ceford]

Looks good. I was looking for a box to tick. Is it waiting for you to set Ready for Reviw?

[max123kl]

There is nothing to tick unless a task list is added.
The draft status is used to block the merging of an unfinished work.
A review is only useful when the work is finished. Any change can be suggested directly in the relevant file line. This then triggers an "open discussion". I'll try to demonstrate this in PR.