Wiki can be edited by any user

[emagdalenaC2i]

Actually, I just edited it unintentionally.
I expected to receive a warning preventing me from saving the changes, but it was not.

But, I was trying to edit the wiki because I think it can be a good system to record the evolution of module migration. Replacing the migration issues like #75

So, any non-technical user can edit / follow the evolution of the migration.

See https://github.com/OCA/stock-logistics-reporting/wiki

[rousseldenis]

Ok, we maybe need to restrict wiki editing to team members.

@OCA/board shouldn't the setting that restrict wiki editing checked by default in all repositories and then let team members decide what to do?

[dreispt]

My opinion is that it should be kept open, and promote wiki edits to grow an OCA knowledge base.
Wiki is easily accessible to non-technical people, and using Github's one has the advange of keeping code and docs in the same place.

If we have content that rally needs approval before it is changed, we should use repository files for that, so that it need to go through a pull request.

[emagdalenaC2i]

I am doing some tests and I trully like it. Not only to add information about the repository and the modules but also to move the migration issues to the wiki

As you can see I can revert a commit easily

[emagdalenaC2i]

This is a test to move the Migration issues to the wiki https://github.com/OCA/product-attribute/wiki

• https://github.com/OCA/product-attribute/wiki/Migration-to-version-12.0

• https://github.com/OCA/product-attribute/wiki/Migration-to-version-13.0

It would also allow to recover the tables of addons:

• https://github.com/OCA/product-attribute/wiki/Migration-to-version-10.0

[mymage]

I think that keep open the possibility do edit the wiki is a bit hazardous: using team policy isn't only a way to keep out people that eventully haven't good intention (on wiki there isn't a version control to roll back, right?) but it is a step to direct all people contributin to use a common format.

[emagdalenaC2i]

on wiki there isn't a version control to roll back, right?

Yes, there is. You can also clone the wiki as an usual project

[pedrobaeza]

That's just the opposite of what I want, or bad things will happen:

OCA/oca-github-bot#97 (comment)

[emagdalenaC2i]

So, should the wikis be restricted to team members? or should be open but focused on documentation?

[pedrobaeza]

I let that decision to be made, but definitively not for migration issues.

[emagdalenaC2i]

ok, I agree. If a bot can do a task for me, I am pretty sure it will do that better.
Also the bot will not update the migration issues only every 3 or 4 months

[dreispt]

This is probably a bad place to discuss this, and is probably a dumb idea, but did you consider generating one issue per module to migrate with a "13.0-MIG" milestone, and then track the milestone?

[simahawk]

@dreispt I like the idea. It makes easier to handle it w/out complex tools to deal w/ it. PRs can the reference the issue and close it as they are merged.

[pedrobaeza]

That's going to generate a lot of noise, and most modules doesn't need such discussion. They just need to be migrated.

[simahawk]

Reported here OCA/oca-github-bot#101

@pedrobaeza I partially agree w/ you. There's a very good part: you leverage GH features and you don't have to maintain a complex script to deal w/ it.

[pedrobaeza]

It's not a complex script to deal with it... Do you prefer to deal with a repo that will have 100 opened issues for modules that may not be migrated and that complicates any search? Please don't open new battlefields.

[dreispt]

An Issue is a pending task. If we have 100 issues, it's because there are 100 tasks waiting to be picked up. These are usually good starting points for new contributors.

Honestly, smaller repos will be far from that number.
And on big repos today we already deal with hundreds of open items, and It doesn't seem to be a big deal.

And the upside is that the list of pending + done migration tasks is self updateable.
As a maintainer, it is a waste of my time doing duplicate housekeeping work.
It should be enough to update Tags and Milestones. (Even those may be redundant with proper titles).

[pedrobaeza]

You will tell me when they get stacked version per version. My vote is negative, the same as in the past with other actions you have taken, but if you want to continue, go ahead, and in the same manner, you will see that they are not effective.

[dreispt]

It seems that you feel that there will be a accumulation of open migration related issues, and these will be a problem.
I'm sure we're all looking forward to a better way.

What kind of problems do you think these could cause to repo maintainers?
How do you avoid duplicated housekeeping then?
How do you handle later merged modules, that should also be added to the migration list?

[emagdalenaC2i]

I suposse this is not the only Open source project in which they have this type of issues. How is it managed in other similar projects?

[pedrobaeza]

@dreispt the ocabot migration commands will allow a better management without that flooding.

@emagdalenaC2i our flow is different from other open source projects where they don't have such parts (modules) to be handled apart.

[dreispt]

the ocabot migration commands will allow a better management without that flooding.

OK, let's explore that option.
Is there an RFC of PR to have a look at?

[pedrobaeza]

OCA/oca-github-bot#97

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.