►
From YouTube: Manage:Compliance + Plan:Project Management discuss compliance, custom fields, workflows, and more
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
so
I
wanted
to
get
together
to
talk
a
little
bit
about
some
of
the
stuff.
You
were
working
on
with
you.
Compliance
I
read
through
the
issue
a
little
bit
yesterday
and
the
compliance
framework
you're,
putting
together,
which
is
cool
and
I,
want
to
understand
how
things
should
or
should
not
overlap
with
in
the
plans
age.
A
So
there
are
certain
things
that
are
coming
up
with
I'm
talking
to
larger
companies
that
around
enforce
workflows
would
be
one
of
those,
even
something
as
simple
as
like
multi-level
approvals
and
merge
requests,
but
mainly
they
said
in
issues
to
verify
and
before
they
will
accept.
The
issue
from
the
engineer
that
is
behaving
is
expected
and
to
not
let
merger
quest
get
merged
until
that
happens.
A
So
that's
one
item
that
seemed
like
it:
overlaps
with
compliance
a
little
bit,
because
some
of
the
reasons
why
they
want
enforce
foreclose
our
compliance
related.
As
in
like
that,
he
didn't
have
their
legal
team
review
ever
a
piece
of
user-facing
copier
content
that
changes
before
it
can
be
published.
That
sort
of
thing
right
and
then
the
other
area
of
topic
is
this
custom
fields,
and
there
are
lots
of
use
cases
why
people
want
custom
fields
on
everywhere
and
get
loud
pretty
much.
A
Some
of
them
are
for
auditing.
Some
of
them
are
for
compliance
purposes,
some
of
them
or
simply
to
track
like
what
piece
of
hardware
a
given
project
is
running
on
or
assigned
to,
and
all
the
way
down
to
people
want
custom
attributes
on
issues
to
track
certain
data
and
fields
that
we
don't
currently
have
and
get
lab,
and
some
of
them
are
compliance
related.
Some
of
them
are
not
so
there's
like
a
lot
of
overlap
there
and
I'm
not
sure
like
how
to
approach
it.
B
Yes,
so
all
of
that
makes
sense
to
me
and
fits
in
with
the
theme
of
when
you
target
enterprise,
you
necessarily
target.
You
know
the
earn
have
to
satisfy
those
compliance
requirements
and
those
compliance
requirements
are
going
to
be
varied
between
each
org,
because
each
org
writes
their
own
policies
that
dictate
how
they
behave
and
then
they're
audited
against
those
policies,
and
so
an
auditor
comes
in
the
company.
A
it
says
show
me
what
you
say:
you're
doing
for
software
development,
they
say.
B
Oh,
we
do
these
ten
steps
that
cool
show
me
you
actually
doing
those
things
and
then
they
go
to
Company.
B
become
B,
B
has
36
steps,
and
so
they
get
audited
more
thoroughly
and
so
they're
they're
trying
to
make
their
lives
easier
by
having
gitlab
provide
that
customization
aspect
through
custom
fields
to
say:
I
want
to
have
all
this
data
here,
because
it's
easier
for
me
to
track
for
my
internal
audit
program,
but
that
doesn't
make
it
any
less
challenging.
B
It
just
makes
it
understandable,
and
so
that
being
said,
the
reason
we
went
the
path
we
did
on
compliance
labels
for
projects
was
because
a
recurring
theme
and
the
compliance
mindset
is
I.
Have
these
processes
I
need
to
enforce?
The
simple
example:
that's
often
cited
is
like
I
need
at
least
two
people
to
approve
any
change
at
the
merge
request,
and
so
we
said,
okay.
Well,
let's
make
that
our
first
iteration,
let's
give
you
some
of
those
merge,
request
approval
settings
at
the
instance
level,
and
so
then
we
did
that
and
they
said
well.
B
This
is
too
broad
because
I
don't
need
it
for
all
of
my
projects,
I
just
needed
it
for
the
regulated
ones,
but
I
don't
have
to
manage
it
at
the
project
level
and
in
some
cases
I
don't
want
to
manage
it
at
the
group
level,
because
this
is
like
an
organizational
policy,
so
we
said
okay.
Well,
how
do
we
refine
this?
B
Selecting
projects
doesn't
make
sense,
necessarily
because
if
you
have
hundreds
or
thousands
of
projects,
then
that's
also
tedious,
and
so
we
thought
well,
let's
maybe
introduce
concept
of
compliance
labels
and
so
by
labeling
their
projects,
we're
doing
feature
parity
with
the
API
projects
API.
So
they
can
do
that
programmatically.
You
could
then
say:
I
want
to
enforce
these
settings
for
projects
that
are
labeled
with
any
framework
or
maybe
even
just
specific
frameworks,
maybe
even
eventually
have
like
a
profile
per
framework.
A
B
A
Think
like
looking
at
labels,
that's
where
I've
seen,
that
is
overlapping
solution
to
lots
of
problems,
but
it's
almost
to
the
point
where
we
relied
on
it
too
much
now
that
it's
we're
going
backwards
a
little
bit
and
taking
the
most
the
biggest
use
cases
for
labels
and
converting
them
into
first
class
like
fields
like
an
issue
type
for
example
or
like
we
want
to
eventually
get
towards
different
workflow
statuses
right.
Is
it
like
a
first
class
thing
so
I
think?
A
That's
where,
like
there
is
some
overlapping
solutions,
especially
with
the
idea
of
like
compliance
labels,
and
now
we
have
topics
which
I
didn't
know
about
until
that
not
too
long
ago,
when
I
inherit
projects,
and
then
we
have
this
custom
attributes
API.
That
will
let
you
set
custom
attributes
programmatically,
but
it
doesn't
service
them
in
the
UI
anymore,
so
I
I
bet
somebody
contributed
that
to
solve
the
problems
that
they
needed.
You
know
so.
B
A
B
A
B
Far
as
I'm
aware,
there's
no
audit
events
for
that
and
there's
no
way
to
programmatically
apply
it
under
some
criteria
like
newly
created
projects
or
things
of
that
sort,
maybe
via
API
I
guess,
but
that
requires
custom
work
on
their
end.
But
I
think
that
the
custom
attributes
feature.
If
that's
what
I
think
it
is.
B
Maybe
that
I
think
you
mentioned
and
slack
as
well,
like
maybe
that
deprecates
topics
and
we
run
with
that
and
we
present
it
in
the
UI
and
I
think,
even
if
we
did
that
my
opinion
is
the
compliance
framework
label
would
still
exist.
But
then
the
custom
attributes
would
allow
customers
to
refine
further.
So,
like
you
could
maybe
say:
okay.
This
is
a
Sox
project
that
we
label.
B
But
then
we
use
the
custom
attributes
field
to
say
that
maybe
the
more
like
compliance,
technical
way
would
say:
let's
label
it
a
section
400
and
then
that
tells
their
internal
systems
and
team
that
that
has
certain
requirements
or
you
could
even
you
use
custom
attributes
to
say
like
separation
of
duties
or
two-person
approvals
and
then
based
on
those
custom
attributes.
They
can
maybe
manage
certain
workflows.
A
The
other,
the
other
area
is
kind
of
like
there's
been
requests
to
have
protected
labels,
which
would
more
or
less
unless
you
are
a
certain
person.
You
cannot
add
or
remove
labels
from
an
issue,
and
it
goes
back
to
the
same
thing
of
allowing
anybody
to
just
like
add
fields
or
if
it
was
a
topic.
Anybody
could
change
that
and
I
think
I
wasn't
sure
how
to
approach
that
and
make
it
like
an
optional
thing.
But
it
is
sort
of
like
where
there's
a
recurring
theme.
B
Do
you
think
that
if
it
was
something
available
via
like
a
service
account
or
API
that
they
could
build
themselves,
that
it's
not
default,
behavior
we
permit
or
provide,
but
they
could
build
it
to
be
restrictive
in
that
way
through
some
other
mechanism
as
an
option
there,
or
do
you
just
not
like
the
idea
period?
It's.
A
Not
that
I,
don't
like
it
it
just.
It
adds
a
lot
of
complexity
from
like,
if
I'm
an
engineer
working
on
the
issue,
board
and
I
want
to
drag
an
issue
like
from
one
board
to
the
next
right
like
we
would
have
to
throw
an
error
that
doesn't
let
them
do
that
or
if
I
want
to
go
and
select
an
issue
from
a
drop-down,
we
would
have
to
either
not
show
it
or
make
it
not.
A
B
I
wonder
I
mean
maybe
maybe
this
doesn't
solve
the
complexity
issue,
but
I
wonder
if,
rather
than
preventing
everyone
or
allowing
only
certain
people
to
make
those
changes,
if
you
like,
if
we
could
build
in
a
mechanism
that,
if
I,
if
this
label
is
somehow
identify
it
as
like
hard-coded
for
this
issue
and
it
gets
removed
by
whomever,
maybe
then
it
just
gets
reapplied
automatically
kind
of
like
a
built-in
gitlab
bot
type
of
thing.
But
I
don't
know
if
that
solves
the
complexity
issue
that
you're,
referring
to
you,
maybe.
A
Maybe
not
I
think
that's
one
area,
the
other
one
is
the
custom
fields.
The
reason
why
I
haven't
wanted
to
build
it
yet
is
the
government's
behind
it
and
I
don't
want
to
get
to
the
point
where
I,
like
you,
open,
which
I've
seen
in
a
lot
of
our
competitors
through
our
customers
done
by
them
to
me,
like
littered
with
a
bunch
of
like
fields
in
the
sidebar
or
somewhere,
that
never
get
filled
out
and
nobody
uses
them
and
nobody's
knows
what
they're
for
or
why
they
exist
and
there's
not
like.
A
A
How
many
issues
is
currently
being
used
on
or
where
the
data
is
populated
and
then
like
almost
like
an
owner
of
somebody,
who's
responsible
for
that
custom
field,
so
that
anybody's
like?
Why
are
we
using
this?
They
can
go
and
say
this
person
is
responsible
for
this
custom
field
and
why
it's
there
talk
to
them.
If
you
don't
like
it,
you
know.
A
B
You
say
yeah,
that's
great,
but
I
need
it
to
be
tweaked,
and
this
ever
so
slight
way,
because
the
way
that
you're
proposing
it
doesn't
work
for
me
but
I
think
it's
a
bit
simpler,
relatively
speaking
in
this
case,
because,
like
I
think
we
know
what
this
will
be
more
or
less
looks
like
in
terms
well.
We
just
need
to
provide
customization
like
these
custom
fields,
but
I
think
it
sounds
like
what
we're
getting
where
the
biggest
challenge
is.
Then
the
complexity
of
that
on
the
backend
primarily
or
is
it
like
a
UX
thing?
A
Ux
thing
in
the
back
end
for
custom
fields
is
easy
like
if
I
were
to
want
to
add
custom
fields.
It's
the
same
thing
that
way.
Custom
attributes
are
work
right
now,
there's
key
and
a
value,
and
you
can
specify
with
Kia's
and
then
you
can
fill
out
the
value
like
that's
what
a
custom
field
is
so
technically,
that's
not
hard,
but
it's
the
whole
ongoing
life
cycle
of
managing
custom
fields
and
understanding
why
they
exist
who's
responsible
for
them.
How
they've
been
changed?
A
How
they're
currently
being
used
like
that
whole
governance,
piece
to
make
sure
that,
like
you,
don't
end
up
with
this,
like
weird
set
of
all
these,
like
data
points
and
custom
fields
that
you
don't
know
what
to
do
with
you,
don't
know
how
to
migrate
them
or
get
rid
of
them.
You
don't
know
why
they're
bringing
you
some
places
and
not
others.
If
that
makes
sense,
and.
A
B
So
like,
let's
just
assume
for
a
second
that
we're
we're
talking
purely
compliance-
and
this
is
like
a
collaborative
thing
that
you
and
I
are
doing.
I
would
love
to
take
on
the
governance
piece,
because
I
think
that,
even
with
like
issue
labels,
I
I'm,
not
aware
of
a
place,
I
can
go
to
look
at
who
maybe
I.
Can
that
that's
in
governance
info
like
what?
What
issues
are,
how
many
issues
isn't
label
associated
with
who
created
it,
who's
maintaining
it?
When
was
it
last
used
that
kind
of
stuff,
mm-hmm.
A
B
For
custom
fields,
it's
definitely
I
definitely
agree
with
you
there
that
like
if
we
could
show
some
view
that
says,
here's
a
list
of
all
your
custom
fields.
Here's
how
many
issues
it's
current.
It
has
some
value
on
so,
like
maybe
there's
you
know,
it's
gonna
be
on
every
issue
in
theory,
but
then
there's
only
like
ten
issues
where
it's
being
used,
you
can
say
when
that
field
was
last
updated
on
an
issue
who
created
it.
B
You
know
the
the
data
that
you're
talking
about,
because
I
think
you
could
it
would
achieve
what
you're
talking
about
is
like
that
pain
point
of
how
do
we?
How
do
we
manage
this
to
where
it's
not
this
huge
headache?
We
don't
lose
all
this
sort
of,
like
tribal
knowledge
of
who
originally
created
these
things,
and
now
it's
just
a
headache
for
all
of
us
who
have
to
inherit
this,
and
we
don't
even
know
if
it's
necessary
anymore,
but
then
from
the
compliance
side
for
the
organizations
that
are
using
these
fields
for
compliance.
A
B
Its
large,
it's
largely
been
isolated
to
merge
requests
and
the
linked
to
an
issue
so
like
the
only
enforced
workflow
that
I've
heard
of
is
I
want
to
make
sure
that
this
merger
quest
has
an
issue
that
contains
the
business
case
for
the
change
and
there's
also
a
tie-in
to
things
like
service
now
so
like.
Is
there
an
issue
that
describes
the
change?
B
Is
it
linked
to
a
change
management
ticket
or
change
control
ticket
in
something
like
ServiceNow
and
then
the
MRR
is
that
final
gate
before
it
gets
approved
or
merge
into
production,
so
enforce
workflows
as
you've
described?
Them
is
not
something
I've
personally
come
across
yet,
but
maybe
I'm,
just
not
on
those
conversations.
Yeah.
A
Are
you
and
about
linking
em
are
two
issues.
We've
talked
a
synchronously
a
couple
times
about
needing
to
improve,
like
that.
What
that
means
right,
since
you'd
like
related,
is
not
necessarily
like
implements
or
the
canonical
thing
that
is
fixing
the
issue.
Do
you
have
that
on
your
roadmap
to
dress,
because
if
not
I
was
gonna
put
it
on
mine
to
figure
out,
as
that
also
ties
in
to
release
evidence
and
stuff
that
I've
been
talking
to
Jackie
about
yeah.
B
It's
not
an
immediate
priority,
I
think
the
last
interaction
you
and
I
had
was.
You
had
shared
an
issue
where
you
were
gonna
I,
think
you
were
exploring
adding
a
field
I
think
the
Mr
was
DMR
yeah,
the
Mr
sidebar
and
like
having
a
field
there,
that
you
could
link
the
issue
that
corresponds
to
it
and
then
I
think
my
thought
there
was.
That
would
be
a
great
first
iteration
and
then
the
compliance
iteration
would
be.
Let's
allow
that
to
be
enforceable.
So,
like
you
can't
merge
it.
B
The
group
owner
or
admin
could
have
a
setting
or
something
that
says
require
that
M
ours
for
these
compliance.
Labeled
projects
have
a
linked
issue
in
that
field.
I
don't
mind
if
you
want
to
take
that
on.
If
that's
something,
that's
a
higher
priority
for
you,
I
think
from
my
perspective,
I
would
just
wait
until
that
first
iteration
existed
and
then
I
could
act
on
that.
Okay,.
A
A
Is
this
custom
workflows,
piece
I'm
where
you
have
more
States
than
just
opened
and
closed
and
I
thought
through
lots
of
different
ways
to
solve
for
this,
but
one
of
the
things
that
I
was
looking
at
is
we
have
this
value
stream
analytics
now,
where
you
can
customize
the
stages
right,
so
you
can
name
it
you
can
like
specify
which
event.
So
if
it's
a
label
added
or
removed,
we
can
probably
add
more
events
and
then,
when
it's
it
stops.
A
Until
these
events
have
been
satisfied
and
that
seemed
like
I
wanted
to
double-check
with
you
I
I,
don't
know
how
far
we'll
get
in
towards
in
terms
of
enforcing
that,
whether
like
well
it'll,
complete
block
or,
if
that's
just
the
thing
that
you
can
flag
and
put
in
an
auto
report
somewhere
that
the
event
didn't
happen.
So
I
don't
want
to
be
overly
restrictive,
but
I
also
want
to
have
clear
traceability
so
that
organizations
can
like
have
transparency
and
then
talk
with
people
who
don't
follow.
Policies
now
so
want
to
get
your
opinion
on
that.
A
B
Where
in
what
you're
proposing
I
think,
if
you
take
a
more
passive
approach
and
just
alert
off
of
it,
developers
or
users
can
still
maintain
their
velocity
and
they
can
still
continue
to
work.
But
then
management
or
the
appropriate
stakeholders
can
still
talk
to
them
with
the
assurance
that
necess,
you
may
not
necessarily
ship
something
undesirable
now,
if
there
is
some
condition
in
there
where
bypassing
a
state
could
lead
to
a
change
in
production
that
that's
where
you
would
want
to
take
some
stronger
action
potentially,
but
that's
just
my
initial
thoughts
on
it.
Okay,.
A
It
also
is
a
little
bit
less
humane
and
so,
like
I'm,
trying
to
wave
my
way
through
and
be
like
what
our
company
values.
What
do
we
want
to
help
other
teams
strive
towards,
even
if
they
currently
think
that
they
need
like
these
things?
Can
we
show
them
a
better
way?
And
how
do
we
know
that?
So
it's
it's
been
an
interesting
complex
thing
to
think
about.
So.
B
Yeah
and
I'll
just
I
know
what
time
the
last
thought
I
had
was
on
the
show
them.
A
better
way
is
what
I
found
with
you
know.
Tackling
a
different
project
is
that
for
maybe
many
customers,
that's
possible
and
that's
relatively
easy
to
do.
But
when
you
start
talking
about
compliance
minded
customers,
you
know.
B
A
That's
great
great
feedback.
Alright,
thanks
for
sharing
I
will
keep
you
up-to-date
on
how
things
progressed
within
our
the
planning
stage.
Likewise,
and
let's
figure
out
I'm
gonna
thing
a
little
bit
further
about
the
custom
attributes
and
the
topics
and
all
that
stuff
and
hopefully
maybe
come
up
with
a
proposal
next
week.
That's
right,
we
can
start
discussing
so
appreciate
your
time.
Yeah.