<div dir="ltr">I would suggest we get a Phabricator project to track new projects under review, with a public workboard and everything.<div><br></div><div>Running automated tasks and checks can be done using a mix of Herald and Harbormaster. Those can be used to add comments and track status on a Phab task. I suspect we can configure Herald to do things to a task once the two months are up so we don't have to manually track time.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br>Freundliche Grüße<br>Boudhayan Gupta<br>KDE e.V. - Community Working Group<br>+49 151 71032970</div></div></div></div>
<br><div class="gmail_quote">On 28 July 2017 at 23:04, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El dimecres, 26 de juliol de 2017, a les 12:39:12 CEST, Jonathan Riddell va<br>
escriure:<br>
<span class="">> At the BoF today we approved the draft lifecycle policy as a<br>
> reflection of current practice.<br>
><br>
> One addition is that apps in kdereview should take no more than two<br>
> months and after that should be moved to unmaintained or back to<br>
> playground.<br>
><br>
> More notes were taken on discussion about improving the review process<br>
> which Luigi will send.<br>
<br>
</span>Notes at <a href="https://notes.kde.org/p/akademy-2017-application-lifecycle" rel="noreferrer" target="_blank">https://notes.kde.org/p/<wbr>akademy-2017-application-<wbr>lifecycle</a><br>
<br>
It seems to me in the BoF there was a general consensus (even though it may be<br>
just me projecting) that having kdereview for now is better than having<br>
nothing. Once we get those great new tests, it seems everyone was happy with<br>
removing/simplifying greatly the kdereview step.<br>
<br>
Now what we need is a group to step up, collect the checks we do on the<br>
kdereview step (some of them are in the notes) and write those checks.<br>
<br>
Best Regards,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Jonathan<br>
><br>
> On 24 July 2017 at 18:51, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br>
> > We'll have a BoF for that on Wednesday 11:30 in room 2.4.<br>
> ><br>
> > On Sunday, 23 July 2017 19:08:12 CEST Valorie Zimmerman wrote:<br>
> >> Hello folks, I would just like to ask if there is a BoF scheduled<br>
> >> about this? Has a Phab board been created? As a GSoC admin for KDE, we<br>
> >> are always trying to urge/require students to include writing tests as<br>
> >> part of their daily coding, as well as documenting their code /<br>
> >> creating APIdox / writing user docs.<br>
> >><br>
> >> If the group of developers interested in creating this thinks that<br>
> >> this testing regimen is too difficult to get done in a short time, how<br>
> >> about creating a plan for a prospective Season of KDE student? Some<br>
> >> sort of infobox on every application website that continuously reports<br>
> >> test coverage, translation/<wbr>internationalization/<wbr>localization<br>
> >> statistics and other relevant information could be very useful. A<br>
> >> number of you interested people could be resources for such a student<br>
> >> or students.<br>
> >><br>
> >> We are already making the idea of seeking review for commits desirable<br>
> >> and even standard in KDE. The same could be true for automated test<br>
> >> coverage of the entire KDE codebase.<br>
> >><br>
> >> Valorie<br>
> >><br>
> >> On Mon, Jul 17, 2017 at 10:21 AM, Sandro Knauß <<a href="mailto:sknauss@kde.org">sknauss@kde.org</a>> wrote:<br>
> >> > Hey,<br>
> >> ><br>
> >> >> Having automated checks would be great but I see no practical proposal<br>
> >> >> for<br>
> >> >> how to get those.  I'm not even sure it's possible to automate<br>
> >> >> questions<br>
> >> >> like "should this be translated?" or "are all the licences clear?".<br>
> >> ><br>
> >> > well for "are all the licences clear?" are several tools to check the<br>
> >> > license for files. That at least would give us the first step, if we<br>
> >> > would arrange, that every file must be detectable by this tool. I could<br>
> >> > also create a script, that simply can be fired to the repos.<br>
> >> ><br>
> >> > Than at last manual step to check if the different license work<br>
> >> > together<br>
> >> > is a lot faster, because you know already the different licenses of all<br>
> >> > the files.<br>
> >> ><br>
> >> > Best Regards,<br>
> >> ><br>
> >> > sandro<br>
> ><br>
> > --<br>
> > Volker Krause | <a href="mailto:volker.krause@kdab.com">volker.krause@kdab.com</a> | Director Automotive<br>
> > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company<br>
> > Tel. <a href="tel:%2B49-30-521325470" value="+4930521325470">+49-30-521325470</a><br>
> > KDAB - The Qt, C++ and OpenGL Experts<br>
<br>
<br>
</div></div></blockquote></div><br></div>