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