<div dir="ltr"><div dir="ltr"><div>Hi, thanks for CCing me, Justin.</div><div><br></div><div>I took a look at the wiki page history, at past mailing list discussions about KDE Review, and at the issues on Invent tagged with KDE Review, and I see three things:</div><div><br></div><div>* The majority of new projects since 2020 up until this year did not have an issue for tracking the KDE Review checklist at all, despite the checklist existing for more than that<br></div><div>* The wiki is indeed ambiguous about when the checklist needs to be filled in<br></div><div>* It's not really well defined who actually gets to check items in the checklist, both allowing the author and not allowing the author were common occurrences<br></div><div><br></div><div>Personally, I think it is fine for the checklist to be filled by the original author too. Some checkboxes do not apply to all cases (we could make this clearer), and the review is supposed to be about
having developers address issues in a project before it becomes 
part of KDE. We just need to have a final check be done by the reviewers before the project passes the review so that there's nothing missing. The important thing is that it the issues are addressed.</div><div><br></div><div>From what I've seen in the mailing list, the checklist ends up being part of the review whether the actual checklist issue exists (Invent process) or not (mailing list process). Requiring the checklist to be filled before sending to the mailing list is probably too much and only works if the developer is already familiar with REUSE, Docbook, Gitlab CI, Appstream, Localization, etc. It makes more sense to me to have the checklist be filled gradually during the KDE Review, and by the end of the review most or all checkboxes should be ticked. Or is it expected that by the end of an Incubation but before the KDE Review takes place the project developer should already be familiar with all these?<br></div><div><br></div><div>On the matter of the checkboxes being less optimal, we could just remove the ambiguities in the docs and make it a guideline that the developer, when creating an issue for KDE Review, should start the issue with all checkboxes blank so the activity history shows up properly and everyone knows who ticked what.<br></div><div><br></div><div>Cheers,</div><div>Thiago<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 2 de out. de 2023 às 22:31, Justin Zobel <<a href="mailto:justin.zobel@gmail.com">justin.zobel@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think it's clear we need some sort of process documentation for KDE <br>
Review, who is expected to do what, and in which order.<br>
<br>
I've  cc'd Thiago on this as they are KDE's documentation writer, let's <br>
see if we can get something together.<br>
<br>
On 3/10/23 07:42, Carl Schwan wrote:<br>
> On Monday, 2 October 2023 21:53:06 CEST Albert Astals Cid wrote:<br>
>> This method of review is really sub-optiomal.<br>
>><br>
>> Who checked all those marks? There's no way to know.<br>
>><br>
>> Was it someone expert in the area?<br>
>><br>
>> Was it someone that knows has no idea what the checks mean?<br>
>><br>
>> Or was it the submitter of review? If it's the submitter for review it's<br>
>> worthless (nothing against Carl, you're great) but one doesn't review their<br>
>> own MRs, so one shouldn't probably review this kind of checks either.<br>
> I now unchecked all the checkmarks. For me I see these checkmarks as stuff I<br>
> need to do before sending a mail to kde-core-devel, as it is just the basic<br>
> stuff and it doesn't make sense to request a review if this is not done.<br>
><br>
> Cheers,<br>
> Carl<br>
><br>
><br>
><br>
><br>
</blockquote></div></div>