►
Description
GSoC 2022: Plugin Health Score Project Idea - April 7, 2022
Brainstorming Together About Ideas and Alternatives
Objective
Meet for 60 minutes with those interested in the Plugin Health Score project idea to discuss ideas and alternatives and to identify areas where there may be questions. Encourage discussion of different alternatives and ideas that might lead us to a better implementation.
A
A
B
A
B
B
A
B
B
C
A
B
B
B
D
D
So
we
can
maybe
another
way
of
getting
that
info
from
them
would
be
like,
maybe
make
a
google
form
and
then
give
it
to
them,
and
in
those
google
form
they
will
be
question
like
how
important
do
you
think
a
jenkins
file
presence
needs
to
create
in
a
repository
and
mark
it
from
a
score
of
one
to
five,
most
likely
least
likely
not
much
likely
very
likely
and
then
neutral.
Something
like
that,
and
all
the
responses
will
go
to
a
spreadsheet
like
excel
of
some
kind
and
then
from
there.
We
can
do
some
things.
B
B
B
I
one
side
note
I
don't
think
having
a
natural
point.
I
do
like
the
one
two
five
or
one
zero
to
five
or
something
like
that.
But
I
don't
feel
like
having
a
neutral
answer
is
a
good
idea,
because
we
want
people
to
take
a
side
and
yeah,
and
if
we
offer
a
natural
answer,
someone
might
feel
like.
I
don't
my
think.
B
I
don't
know
so
I'll
put
the
neutral,
and
then
we
will
have
all
natural
or
mostly
neutral
answer,
but
we
want
people
to
take
side
and
also
we
have
to
remember
that
that
would
be
for
the
first
set
and
only
for
those,
because
in
the
long
term,
as
we
said
last
week,
the
weight
of
the
rules
would
evolve
during
the
time
because,
for
example,
at
the
start,
having
a
jenkins
fight
is
very
important.
I
already
saw
that
out
of
the
1800s
plugins
only
600
600
of
them
don't
have
a
jenkins
file,
but.
A
B
And
so
we
could
say
for
now.
It's
a
good
thing
to
have
java,
17
support,
and
maybe
in
one
year
one
18
months,
we
will
say
having
java
having
java
17
support
is
mandatory
or
not
mandatory,
but
very
important,
because
we
are
about
to
put
the
whole
project
in
to
be
to
be
able
to
support
java
17..
So
I
I
I
think
we
need
to
also
have
that
kind
of
notion
that
the
the
scoring
the
weight
of
the
rules
will.
E
C
It's
an
easy
way
to
keep.
You
know
to
log
the
data.
Essentially
my
one
concern,
I
guess
with
the
survey
is
getting
people
to
take
the
survey
I
mean
I
mean
I
guess
it
would
be
the
same
as
responding
to
an
email,
but
in
my
experience
that's
always
the
tricky
part
with
service.
Is
it's
getting
people
to
actually
take
the
survey.
B
E
A
May
suggest
two
things
we
can
set
the
system
in
place
and
do
a
quick
run
of
it,
but
I
I
wouldn't
like
the
the
contributors
to
be
blocked
in
the
development
for
that.
So
it's
it's
a
task
that
we
can
do
on
the
product
itself,
but
and
it's
important
to
have
a
general
point
of
view
of
the
community
and
we
can
put
something
in
place
to
do
that
regularly.
But
during
the
summer
we
need
to
move
to
move
ahead.
B
A
B
Can
assure
you
it's
not
so
impressed
so
that
that
will
show
us
and
it's
an
easy
win,
also
for
any
plug-in
maintainer
to
raise
the
score
of
the
of
of
a
plugin.
That
would
be
also
an
easy
win.
To
just
add
the
jenkins
file.
It's
pretty
easy.
The
contribution
guide
that
mark
and
new
jerk
built
well
document
is
the
the
way
to
yeah
it's.
It's
really
easy
and
then
well
documented.
So
anyone
can
can
have
that
and
it's
an
easy
win
for
anyone
for
any
new
contributors.
D
Definitely
answered
my
question
and
I
got
what
to
expect
and
what
to
do
if
unexpected
thing
happens
like
if
we
do
not
get
any
responses,
so
my
question
would
be
on
again
not
again,
but
on
the
frequency
of
this
changes
of
weight.
So,
as
you
said,
we
can
have
some
changes
of
these
weights
as
per
a
moment
when
we
feel
that
our
11
or
something
version
should
be
preferred
so
that
frequency
would
be
like
would
not
be
very
too
frequent
right.
A
D
B
I
don't
think
that
during
this
summer,
we
I
think
during
this
summer
we
will
change
those
scoring
the
weight
a
lot
not
every
day,
but
I
guess
at
least
once
a
week,
because
either
we
get
feedback
or
not
or
stuff
like
that.
I
don't
want
to
say
that
we
won't.
We
start
the
the
sum
of
code
with
a
set
of
rules
weighted
at
a
specific
point
and
start,
and
we
will
finish
the
sum
of
code
with
the
sames
with
the
same
rules
and
weight.
B
A
B
Because
I
think
that,
within
the
lcs
period
we
saw
in
the
past
that
we
were
introduced
introducing
a
few
changes
in
core,
I'm
I'm
thinking
about
java
11,
I'm
thinking
about
ui
about
guava
and
and
things
like
that,
and
that
can
also
be
the
source
of
new
rules,
let's
say
and
also
and
see
how
we
can
plan
from
that
and
again
12
weeks.
My
idea
of
12
week
is
just
use
to
review.
B
Them
doesn't
mean
that
they
will
change
and
for
sure
we
don't
want
them
to
change
every
day,
because
we
want
some
stability
in
the
scoring,
so
that
yeah
but
the
so
that's
the
for
the
weight
of
the
rule,
but
for
the
generation
of
the
score.
That
is
another
question
and
I
think
it
should
be
as
soon
as
possible
as
often
as
possible.
C
B
C
Well,
I
mean
because
I
guess
it
depends
right
if
we,
I
guess
this
is
kind
of
dependent
on
how
we
display
the
information
right,
because
if
we,
if
it's
you
know,
it
probably
wouldn't
make
much
sense
to
like
notify
people
on
the
plug-in
site.
But
if
we
were
to,
I
don't
know,
throw
some
sort
of
badge
or
something
like
that.
A
D
B
B
B
Details
on
the
controller
we
shouldn't
have
the
each
each
rule,
the
score
for
each
rule
and
so
on,
because
we
don't
at
that
moment.
I
don't
think
we
care.
Oh,
it's
well
phrases,
I'm
sorry!
It's
not
that
we
don't
care
it's.
I
don't
think
that's
the
most
important
one.
I
think
if
we
want
to
understand
why
the
plugin
has
a
specific
score.
B
The
plugin
manager,
as
a
link,
is
already,
as
already
an
apple
link
to
to
put
you
on
the
plugin
site
of
the
plugin,
with
the
plugin
details,
and
on
that
page
we
can
show
all
the
details
about
the
score
about.
Why
is
it
on
a
plus?
Why
is
it
a
b
and
so
on
and
even
be
more
specific,
because
we
I
here
I'm
saying
letters,
but
we
could
have
the
percentage
and
say
the
plugin
is
a
plus
with
95
percent.
B
999
percent
of
validation-
and
here
are
the
rules
that
are
not
validated
here-
are
the
rules
that
are
validated
not
validated.
So
from
from
past
discussion,
I
had
with
danielle
the
update
center.
The
json
file
that
is
fetched
by
controllers
and
used
for
the
plugin
manager
is
already
quite
heavy.
It's
already
quite
huge,
so
I
I
I
don't
want
to
put
more
data
in
it
than
it
is
required.
I
don't
even
want
to.
I
even
not
sure
we
should
put
the
data
in
this
one
in
this.
B
B
C
C
I
mean,
I
think
it
brings
down
the
cost
right
and
if,
if
all
the
controllers
are
getting
or
fetching
is
just
like
the
composite
score
for
each
plug-in,
I
think
we
could
keep
it
rather
small
and
of
course
you
know
maybe
just
one
link
somewhere
within
the
instance
that
says
hey
you
know.
If
you
need
more
details,
go
check
out.
You
know
the
plug-in
site
where
you
can
actually
view
all
the
details
of
the
plugin.
B
I
think
that's,
it
could
be
even
the
the
badge
of
the
score
that
we
put
in
the
plug-in
plugin
manager
badge
or
the
later
of
of
the
plugin
on
the
plugin
manager.
On
the
controller,
we
could
have
a
link
there
to
see
to
say
more
details
and
that
bring
that's
put
you
in
the
plugin
site
on
the
correct
tab,
or
something
like
that.
B
A
B
It
will
yeah,
I
think,
simplify
the
controller
and
also
not
limit
us,
because
if
we
want
to
only
in
the
controller,
then
we
will
be,
we
will
have
some
size
constraints
and
we
will
need
to
be
to
do
some
sacrifices
on
what
are
the
details
that
we
are
showing.
If
we
get
rid
of
that
constraints
of
size
constraints,
then
we
can,
then
we
can
be
a
bit
more
permissive
with
the
type
of
data
we
show
yeah.
I
do.
I
really
do
like
that
that
that
example.
C
Yeah
yeah,
I
think
you
know
this
is
exactly
you
know
what
we
showed
last
week
or
what
I
shared
last
week,
and
I
think
it
describes
exactly
what
you
were
saying
there
having
a
new
tab.
That
would
give
you
all
the
details
of
the
plug-in
health
score,
and
this
is
what
would
be
linked
from
you
know
what
you
were
saying,
I
believe
from
the
controller
yeah.
B
B
B
Example,
but
we
could
have
links
to
the
open
pr's
we
could
have
for
plugin
is
up
for
adoption.
That
is
an
easy
fix.
That's
an
easy
link
us
to
explain
what
is
why
your
plugin
is
up
for
adoption.
How
to
solve
that.
We
spoke
about
depend
about.
We
could
say
if,
if
it's,
if
dependability
is
not
activated,
then
here's
the
link
here
here
is
the
documentation
on
how
to
activate
it,
and
then
the
plugin
would
have
a
better
score,
but.
A
So
now
I
need
to
defend
a
little
bit
the
contributors
we
can
do
that
in
various
iterations.
So
it's
not
something
that
needs
to
be
done.
We
need
to
to
prepare
things
that
we
can
edit
and
know
how
to
add
it,
but
I
I
don't
want
that.
Well,
I
would
not
recommend
that
contributed.
Contributors
go
to
attack
a
big,
the
big.
B
B
Yeah,
exactly
and
but
it
could
be
a
automatic
when
it's
an
easy
fix,
for
example,
having
the
parent
pump
up
to
date.
We
could
we
can
make
the
upgrade
test
it
and
if
the
build
pass,
then
we
can
submit
the
pr.
But
if,
if
the
pr
is
not
green
out
of
the
box,
it's
more
difficult
and
that's
not
something
that
we
can
do
for
old,
plugins.
D
Yes,
thank
you.
So
would
it
help
if
we
also
link
for
a
particular
parameter,
let's
say
updating
the
parent
form?
If
it's
listed
in
this
page,
so
can
we
link
it
to
the
adopt
the
plugin
tutorial
that
mark
and
aaron
are
working
on
when
it
gets
published
on
the
site?
We
can
attach
that
particular
sections
link
with
this
parameter
so
and
since
it's
explained
there
very
well
so
even
for
new
contributors,
so
they
will
be
knowing
how
to
do
what
we
do.
B
D
About
data
presentation,
guess
one
part
of
it
and
about
data
delivery.
Yes
one
part
of
it.
So
let
me
I
had
one
point
to
add
in
the
previous
section
about
where
we
were
discussing:
how
would
we
notify
maintainers
that
the
rules
have
changed
so
since
adrian
says
that
we
can
change
the
rules,
maybe
with
every
lts
release?
So
what
do
we
think
about
notifying
them
via
the
change
log,
or
would
it
be
effective
like
as
an
entry
that
hey
are
the
new
rules?
Please
go
check
them
out.
I
would
not
be
that
impactful.
A
C
B
We
could
have
an
entry
on
the
lts
change
log
saying
how
the
scores
are
now
evaluated.
That's
a
very
good
point,
but
I
think
that
the
maintainers
of
the
plugins
should
be
notified
in
advance,
because
when
we
I'm
I'm
just
I
I'm
sorry
for
that.
I
didn't
think
about
that
about
the
frequency
of
the
weight
evaluation,
re-evaluation,
yeah.
C
B
B
Prepare
and
again
it's
not,
I
don't.
I
don't
think
that
we
will
change
the
weight
every
12
12
weeks.
I
think
we
need
to
reevaluate
them
so
meaning
maybe
we
will
say
okay,
we
look
into
them.
It's
still
good,
it's
still
what
we
want,
so
we
don't
touch
them.
So
maybe
they
won't
change
every
12
weeks
this
year
that
every
12
weeks
we
looked
at
them.
We
looked
at
them.
C
We
have
a
good
idea
of
the
rule
changes
or
I
guess
if
we
evaluate
rules
somewhere
in
the
middle
with
like
weeklies,
and
you
know-
let's
say
you
know
the
sixth
week
right
that
gives
them.
You
know
five
or
six
weeks
to
adjust
their
plug-in
prior
to
the
next
lts,
where
it
would
really,
you
know,
take
change.
C
B
B
B
A
Jake
and
adrian
I'm
looking
at
the
clock,
so
I
think
these
are
our
important
discussion
and
I
think
it's
important
that
submitters
will
know
about
this
discussion.
What
I
want
to
be
sure,
because
it
will
be
probably
the
last
workshop
that
we'll
able
to
organize
before
you
have
to
submit
your
proposals
so.
D
A
A
A
D
Yes,
thank
you,
so
I
understood
the
discussion
about
how
are
we
going
to
display
it
on
the
plug-in
site,
as
shown
in
this
screenshot
here?
My
question
is
around
another
way
of
another
place
for
it
to
dis,
display
the
things
it
does
not
work
it
just
I
made
it
up,
so
it's
one
of
those
hackathon
ideas
we
have
at
3am,
which
does
not
work
out
so
just
wanted
to
discuss
it
with
you
very
quickly.
D
Yes,
this
one,
so
so
it
would
be
like
a
new
website,
so
its
whole
aim
would
be
to
presenting
comparing
ways
of
improving
the
health
score
of
all
the
plugins,
and
when
you
visit
it,
it
would
look
something
like
it
fully
score
related
and
they
would
be
like
bulletins
and,
like
real-time
kind
of
things,
going
on
saying
that
congratulations
to
xyz
contributor
for
increasing
the
health
score
of
the
parameterized
trigger
plug-in
from
this
to
this.
So
this
plug-in
saw
a
15-point
increase
in
its
health
score.
D
B
C
Aspect-
and
you
know
to
another-
I
think
with
having
it
in
the
plug-in
site
versus
something
like
that.
I
think
we,
we
kill
two
birds
with
one
stone
right
I
mean
we're
taking
care
of
the
maintainers
and
the
end
users
right
the
end
users
get
a
glimpse
into
the
plug-in
health
score
as
well.
I
don't
know
how
we'd
you
know,
sell
it
or
get.
I
don't
know
if
users
would
be
allowed
to
go
to
this
health.jenkins.io,
but
I
think
we're
adding
something
that's
outside
of
their
normal
user
flow
right.
C
B
And
I
think
to
agree
here
having
another
portal
for
anyone
for
a
person
to
to
go
to
and
see
that
kind
of
details,
and
I'm
not
sure,
even
though
it's
good
to
see
a
plugin
going
from
a
d
to
a
b
plus
or
something
like
that.
I
don't
think
that
we
should.
We
should
because
the
side
effect
of
that
is
also
showing
plugins
going
to
b
to
from
a
b
to
a
c,
because
we
change
the
weight
and
it's
not
a.
D
B
B
We
should
put
a
disgrace
on
yeah,
so
I
I
don't
really
it's
a
personal
feeling
here.
I
don't
really
like
the
the
idea
of
showing
a
plugin
x,
gain
15
points
or
stuff
like
that,
even
though
it
can
be,
I
I
do
see
that
it
can
be
rewarding.
I
don't
feel
like
it
will
be
in
the
long
term
or
even
mid-term,
a
good
thing
for
the
for
the
community
and,
as
jet
said,
having
that
having.
A
B
C
C
D
So
another
question
is
about
what
we
have
discussed
already
on
update
center,
since
it's
very
huge
we
do
not
want
to
overburden
it
with
the
parameters
force.
So
my
question
here
is
about
about
what
you
shared
on
the
email
adrian.
So
you
said
that
if
you
want
this
code
to
be
visible
on
any
controller,
only
the
sport
should
be
added,
so
just
needed.
Some
clarity
on
that.
A
B
B
B
A
B
C
B
A
B
D
B
C
D
Okay,
yes,
so
just
to
make
sure
I'm
not
confused.
I
got
what
you're
trying
to
say
here,
but
my
concern
here
is
so
on
plugin
site.
If
we
want
to
display
information
like
this,
we
need
to
have
the
score
for
a
particular
parameter,
so
we
need
to
display
it
or
publish
it
in
this
json
file
right
in
this
form.
So
if
we
do
not
have
it
here,
so
how
would
we
present
it
on
the
plugin
site.
B
A
B
A
B
A
B
A
A
D
D
E
Yeah
yeah
yeah
sure,
so
I
don't
think
we'll
be
able
to
do
that
in
five
minutes.
Actually
I'll
share
some
blogs,
maybe
or
some
video
or
maybe
we
can
have
a
call
set
up
later.
Also,
that's
not
an
issue,
but
since
you
asked
about
algorithm
actually
I
wanted
to
share
that.
I
was
thinking
of
one
and
I
had
created
this
flow
diagram
kind
of
a
thing
for
that.
So
if
it's
possible
I'll
share
the
link
here
and
you
can
maybe
open
up-
I'm
not
sure
if
sharing
this
thing.
E
E
E
B
E
So
I
thought
about
the
various
probes
that
we
discussed
in
the
last
meeting
and
I
thought
that
we
can
divide
it
into
three
types.
One
are
booleans
that
we
have,
whether
a
file
is
present
or
not
the
other
one
is
unbounded,
non-booleans
or,
I
should
have
said
integers
or
floats
there,
but
unbounded
variables
where
it
can
be
number
of
stars
in
a
on
the
repository.
So
that's
something
I
think
mark
suggested
like
time,
and
there
are
some
there
could
be
bounded
non
booleans,
and
here
I
don't
really
have
an
example.
E
E
And
if
that
happens,
we
can
then
scale
it
to
minus
one
to
plus
one
also
for
the
unbounded
case.
Here
I
was
thinking
that
some
transformation,
where
especially
using
some
function
like
sigmoid
or
tannage,
where,
where
these
functions
they
are
known
to,
you
know,
bring
down
a
unbounded
value
to
a
bounded
value.
So
sigmoid
brings
to
0
to
1,
and
tan
h
brings
to
minus
1
to
plus
1,
so
we
can
use
either
them
to
bring
them
down
to
these
values.
E
These
ranges
that
we
want,
and
then
we
can
simply
take
a
weighted
average
where
here
the
weight
by
weighted
average.
I
mean
the
number
of
boolean,
like
one
upon
the
number
of
booleans
into
the
weight
that
we
got
from
the
boolean,
plus
one
upon
the
number
of
bounded
non
booleans
into
the
weight,
the
score
that
we
got
from
non
so
on
and
so
forth.
E
So
why
why
I
said
this
is
because
in
all
three
places
we
will
get
something
between
minus
one
to
plus
one,
but
we
also
don't
want
them
to
give
equal
weightage
to
all
the
three
classes,
because
we
are
not
sure,
like
the
number
of
booleans.
Could
be
the
5
or
10
and
we'll
have
probably
say,
like
50
unbounded
values,
so
that
shouldn't
mean
that
the
boolean
value
should
get
equal
weightage.
So
that's
why?
E
D
A
Okay,
no
problem:
we
are
we're
reaching
the
end
here
questioned
raj.
Do
you
feel
equipped
for
finishing
your
submission?
Yes,
I
think
I
I
think
so,
and
this
will
work.
Somebody
wants
to
add
something
at
the
end
of
this
meeting
over
time.
So
I
thank
everybody
for
the
contribution,
note-taking
and
interesting
graph
from
editia
and
well
we'll
close.
The
call
now.