►
From YouTube: Ortelius Website Working Group Meeting - October 2020
Description
This group of super achievers is working hard to bring awareness to the Ortelius Open Source Project. This Ortelius Website Working Group is defining a road map and new design for the Ortelius Website.
A
Complexity
with
with
scripts
that
are
with
source
code,
that
is
editable
in
asciidoc
or
in
markdown,
and
therefore
contributors
can
submit
things
to
fit
that
site
and
let
it
be
generated
for
them.
I'm
assuming
you
want
a
static
site,
so
you
want
your
pages
to
be
generated
and
then
serve
from
a
static
web
server,
not
something
that
needs
dynamic
programs
to
do
evaluation
of
requests.
Is
that
a
safe,
safe
question
as
well?
Are
there.
C
A
Okay,
good,
so
that-
and
that
was
our
experience-
I
think
we
had
started
some
years
ago-
doing
with
some
pieces
of
the
site
being
generated
dynamically
and
the
load
on
the
site
became
unacceptable
and
we
realized
look.
We
need
to
generate
static
pages
so
that
we
get
the
benefit
of
content.
Caching,
we
get
the
benefit
of
everybody,
just
getting
what
looks
to
them
like
a
read-only
page
and
we're
not
generating
some
computing,
something
at
the
back
end
to
fill
in
fields
in
a
page.
A
A
So,
in
terms
of
our
inspiration,
one
of
the
things
that
inspired
us
was
actually
the
freebsd
project's
handbook
and
so
our
documentation
as
a
product
needed
to
be
expressed
and
the
inspiration
that
led
tyler
croyd
to
do
it
was
he
looked
at
the
freebsd
handbook
and
said
this
thing
is
a
work
of
art.
It's
beautifully
structured,
it's
got
the
right
sequence
of
topics,
and
so
he
modeled
our
documentation,
section
the
the
jenkins
book
on
the
freebsd
handbook
and-
and
that
was
again
taking
somebody's
good
idea
and
trying
to
do
it.
A
The
the
jenkins
book
is
to
me
feels
weak
weaker
than
it
should
be,
because
we
have
15
years
of
a
wiki
that
should
all
be
in
it
and
isn't
yet,
but
it
was
a
good
model
for
us,
so
the
freebsd
handbook
was
a
great
help.
Now
the
site
generation
task
is
is
where
you
get
to
choose
the
tooling
that
you
would
prefer
for
to
generate
the
site
and
we
use
awestruct
awestruck
lets
us
do
code
in
ruby
at
the
back
end
that
helps
with
the
generation
of
the
site.
A
We
use
haml
files
and
ascii
doc
markup
to
to
construct
the
the
final
static
web
pages.
If,
if
I
were
doing
it
again,
I
would
probably
look
at
antora
from
the
same
person
who
writes
and
cares
about.
Ascii
doc
and
torah
is
a
site
generator,
but
all
those
things
are
my
my
mind,
says
for
a
project
the
size
of
jenkins,
with
the
complexity
of
jenkins,
they're,
probably
justified.
A
B
We
don't
have
to,
we
don't
have
to
so
it
is
a
sas
product,
we're
hoping
that
the
cd
foundation
accepts
us
and
we
can
host
a
assass
the
sas
there.
So
we're
not
going
to
have
a
situation
where
we
have
the
the
kind
of
servers
that
jenkins
has
to
to
manage.
So
I
think
the
primary
the
primary
need
of
the
website
is
information
documentation.
B
B
A
I
mean
so
you've
got
the
the
sas
based
execution
engine.
That
would
then
would
construct
this
site
and
its
static
pages
and
then
publish
the
static
pages.
Basically,
so
it
sounds
like
you've
got
a
similar
model
to
the
jenkins
site
where
we
build
it
in
jenkins,
but
it's
actually
published
to
a
kubernetes
server
that
serves
the
pages
correct.
A
Okay,
so
so
then,
then,
now
in
terms
of
of
your
yeah,
I
guess
your
choices
to
me.
It
seems
like
if
you
want,
if
you
think,
you've
got
to
go
to
something
larger.
You
may
want
to
look
at
antora,
see.
Okay,
should
I
use
it
for
site
generation?
If
you'd
like
to
just
do
a
test
drive,
you
could
certainly
fork
the
jenkins.io
site
and
and
experiment
with
it
to
see.
What
would
it
be
like
if
you
wanted
to
do
it
in
awestruck
awestruck
is,
is
antoine.
A
Yeah,
so
so,
let's
see,
maybe
would
it
help
you
if
I
talked
you
through
the
process
for
the
steps
that
are
involved
in
a
change
getting
to
a
user,
so
sure
what
what
does
it
mean
for
a
user?
When,
when
I
want
to
submit
a
new
change,
I
want
to
correct
the
spelling
on
a
word
in
a
web
page
on
jenkins.io.
B
A
A
A
A
A
A
A
B
D
B
A
B
B
B
A
A
B
It's
based
on
a
hugo
server.
Oh
right,
okay,
so
you
can
see
everything
you
know
you.
Could
you
have
a
you?
Basically,
you
have
a
preview
within
doxy
to
see
what
your
markdown
changes
are
going
to
look
like.
I
don't
know
how
interesting
it
could
look.
You
know
if
we
did
something
like
that
and
I've
thought
about
this.
We
may
have
to
have
a
you
know
like
a
wordpress
front,
end
for
now
and
then
have
links
to
doxy
pages
or
doxy
chapters.
B
You
know
if
there's
other,
if
other
ways
of
doing
that,
to
get
there
because
we're
not
as
obviously
we're
not
as
mature
as
as
jenkins,
but
we
don't
want
to
you
know.
I
want
to
make
sure
that
the
the
team
has
the
ability
to
do
contributions
and
we
have
the
ability
to
grow
the
site
in
a
way
that
makes
sense.
E
B
Before
we
finalize
absolutely
absolutely
because
if
we
did
that,
we
would
have
a
better
understanding
of
what
we
needed
to
support
because,
for
example,
I
don't
know,
I
have
never
I've,
I've
never
looked
at
antora.
So
I
I
I
can't
say
if
that
would
work,
but
if
it's
sort
of
like
a
doxy,
do
you
know
what
it
does
is
on
torah
based
on
a
particular
server.
B
F
F
So
if
your
documentation
is
fragmented
across,
say,
multiple
services,
where
you're
keeping
the
documentation
tightly
coupled
and
torah,
can
support
that
out
the
box.
You
can
do
that
with
hugo.
It's
a
same
setup.
I've
done
for
a
couple
of
companies,
internal
documentation,
it's
just
it's
a
little
bit
more
work
to
get
that.
I
think
the
big
difference
so
as
antorus
you're
saying
is
ascii
doc,
based
where,
as
hugo
will
be
markdown
based
as
far
as
the
doxy
component
of
it.
That
can
be
pretty
much
styled.
F
However,
so
that's
really
just
a
couple
of
javascript
libraries
and
some
css
and
a
few
other
bits
and
pieces
to
structure
it
as
a
good
documentation
site.
So
if
there
is
any
kind
of
wireframes
we
do
internally,
that
can
be
pretty
much
adjusted.
Whichever
way
we
need
to
on
the
doxy
and
hugo
side.
So.
A
So
owen,
it
sounds
like
if
you've
got
past
experience
with
hugo
you've.
You've
got
miles
away
more
experience
in
terms
of
comparing
different
dock
generators.
That's
great!
So
the
the
crucial
difference
there
hugo
generates
static
pages
as
well,
then.
So
the
question
then
becomes:
how
do
we
structure
the
site
to
meet
the
needs
of
the
users
which,
which
is
back
to
the
a
good
question?
Should
we
should
we
wireframe
or
discuss
which,
what
style
of
site
would
we
like
it
to
look
like
and
jenkins.io
is
an
interesting
example?
A
You
could
look
at
the
at
the
python
documentation
right,
the
python
site,
or
at
I
mean
there
are
a
number
of
really
excellent
products
out
there
with
the
kubernetes
site
with
people
who
have
thought
very
deeply
about.
Oh,
how
do
we
present
lots
of
difficult
challenging
concepts
in
a
way
that
is
intelligible
to
users,
to
readers.
F
So
vm
the
other,
the
other
site,
which
makes
an
interesting
reference,
is
git
lab.
So
they
did
a
big
piece
of
work
about
four
or
five
years
ago.
I
think
it
was
to
move
over
to
a
static
site
generator
and
they
actually
blocked
and
documented
it
quite
well.
So
there's
a
lot
of
information
there
about
some
of
the
issues
they
run
into
with
that
migration,
which
might
be
relevant
for
us
as
well.
G
So,
I'm
not
sure
if
it's
like
a
feasible
attempt,
but
I'm
just
throwing
out
the
idea
there
if
we
could
probably
prototype
the
different
sorts
of
document,
generators
that
are
out
there,
so
we
narrowed
down
to
we
narrowed
it
down
to
docusaurus,
but
necessarily
not
not
necessarily
that
we
want
to
adopt
it
here
in
this
project,
but
I'm
just
suggesting
it.
As
you
know,
one
of
the
things
that
we
could
possibly.
F
No,
no,
I
had
markets.
What
I
was
going
to
quickly
say
is
one
of
the
things
which
will
be
important
to
take
into
account
with
any
evaluation
is
the
actual
language
which
the
static
site
generator
is
written
in,
particularly
while
we
might
start
with
something
like
a
baseline
or
something
like
doxy.
We
might
find
there's
custom
functionality
or
categorization.
We
want
to
add
in
the
future
and
so
having
a
look
at
the
language
and
what
language
is
likely
to
be
widely
used
with
the
rest
of
the
project
can
be
valuable.
F
A
I
have
to
I
have
to
fully
support
owen's
observation.
One
of
the
things
we've
found
that
has
helped
the
jenkins
dot
io
site
in
its
evolution
has
been
that
we
are
able
to
do
custom
extensions
in
little
snippets
of
in
our
case,
it's
ruby
little
snippets
of
ruby
or
pamel.
That's
ruby
markup,
as
html
has
been
a
great
help
for
us
in
being
able
to
make
the
site
useful.
A
We,
for
instance,
now
do
things
like
read.
The
latest
jenkins
version
number
from
another
location
insert
inserted
into
this
into
the
generated
static
site
so
that
the
site
says
that
jenkins
version
number
is
something
something
does
something
and,
and
that's
one
of
those
things
that
being
able
to
extend
the
site
generation
process
was
crucial
for
us.
So
I
I
I
agree
wholeheartedly
with
owen
it's
it's
I've
been
amazed
at
the
number
of
times.
A
little
bit
of
extension
gave
us
a
whole
new
concept
on
the
site.
A
B
A
G
You
know,
library,
structure
that
you
have
to
give
in
as
input
and
that
kind
of
has
to
include
the
python
libraries
that
they
have
in
the
first
place,
so
building
documentation,
for
that
was
very
difficult,
so
they
were,
and
they
also
wanted
jsx
support,
because
a
lot
of
their
modules
were
going
to
be
written
in
jsx.
So
that's
that's
one,
that's
two
things
that
they
were
looking
out
for
and
which
is
why
docusaurus
fit
the
bill
for
us
perfectly
and
it's
it's.
G
It's
been
a
bit
of
a
a
roller
coaster
ride
if
I
can
say
that
because
markdown
markdown
apart
the
extensibility,
but
it
works
in
very
well
because
a
lot
of
stuff
stuff,
we
actually
need
to
keep
on
adding
and
we
need
to
have
like
a
lot
of
centralization
done
with
respect
to
the
documentation.
So
they
have
a
lot
of
documentation
and
different
disparate.
You
know
location,
so
they
wanted
all
of
that
centralized
so
that
that
was,
you
know
helpful
in
getting
it
in,
and
we
also
had.
G
The
only
thing
that
we
are
actually
looking
at
is
the
jsx
bit,
and
that
is
unfortunately
going
to
come
in
a
stable
release
for
version
two
and
it's
not
there
with
version
one.
So
it
was
kind
of
a
bummer,
but
again
cern
said
that
it
was
gonna,
be
there
or
the
jfx
release
was
going
to
be
there
next
year.
So
I
think
that
perfectly
coincides
with
their
timings.
A
So
so
you
you
had
mentioned
markdown,
I
remember
arriving
to
contribute
to
jenkins
documentation
and
being
oh.
Why
isn't
this
in
markdown
and
I
read-
and
I
think
I
understand
their
intent
in
choosing
ascii
doc
instead
of
markdown
because
of
the
the
far
fewer
variants
there
are
an
ascii
dog
compared
to
the
number
of
variants
there
are
of
markdown,
so
your
choice
of
which,
which
markup
language
is
an
important
choice
for
your
community.
A
F
Yeah
sure,
so
what
you
said
was
absolutely
correct:
ascii
doc's
main
advantages
are
it's
pretty
much
universal
weather
is
support.
There's
not
the
same
variances
between
like
daring,
marked
down
and
get
lab
zone
mark
down
all
of
that
side
of
things.
The
main
drawback
I
would
say,
with
ascii
dot.
Is
it's
not
as
common
in
use
as
markdown
is?
F
If
you
have
markdown,
everyone
can
start
contributing,
and
you
can
kind
of
you
can
limit
the
impact
of
the
variance
of
markdown
by
having
a
good
pipeline
in
place,
something
which
can
give
fast
feedback
to
say.
You
know
this
isn't
valid
in
our
version
and
from
also
just
having
clear
examples
of
what
the
markdown
will
look
like
if
we're
using
github
pages
in
the
end
that
one's
a
fairly
well
understood
syntax
of
markdown,
a
huge
iphone
correctly
supports
the
same
basic
extensions.
F
But
yeah
fully
agree
and
one
of
the
things
I
wanted
to
quickly
say
on
the
from
the
docusaurus.
I
think
that's
a
really
good
example
of
the
the
language
side
of
it,
because
remember
correctly,
jockusaurus
is
react
based,
so
the
plugins
are
written
in
react
which
are
the
extensions,
so
that
will
once
the
functionality
is
available
around
the
dsx
files.
That
will
line
up
quite
nicely
and
it
is
those
kind
of
two
axes
when
you're
looking
at
static
site
generators,
the
first
one
being.
F
What
is
the
markup
syntax,
markdown
ascii
dot?
The
other
options
are
available
as
well,
and
then
the
second
category
you're
looking
at
is
what
is
the
language
which
static
site
generator
is
written
in
and
if
you
can
align
those
you
can
be
in
a
pretty
good
place.
But
you
need
to
evaluate
both-
probably
the
markup
syntax
first,
as
there's
almost
always
some
kind
of
tool
which
will
work
with
that
markup
syntax
in
a
language
which
you're
familiar
with.
A
A
C
And
you
know
we
we
already
have
a
documentation
site
which
has
a
significant
amount
of
doxy
style
markdown,
and
so
you
know
continuing
to
build
that
out.
I
think,
is
probably
a
good
idea
and
to
get
back
to
owen's
comments
on
the
language
thing.
I've
got
a
a
friend
that
spent
a
lot
of
time
studying
these
things
and
we
go
back
and
forth
with
them
occasionally,
and
I
was
just
looking
at
a
site
that
was
having
a
list
of
these
sort
of
things
and
it's,
like
you
know,
80
of
the
stuff.
C
That's
out
there
is
javascript
based
in
in
this
realm,
and
you
know
and
sort
of
hugo
and
a
couple
of
other
things,
sort
of
standalone
as
being
non-non-javascript
sort
of
stuff
and
in
terms
of
ortelius.
This
isn't
an
area
that
I
really
expected
to
be
making
any
major
contributions
to,
and
so
my
distaste
for,
like
writing,
more
javascript.
I
didn't
want
to
inject
that
into
the
process,
but
you
know
if
anybody
else
feels.
C
Similarly
that
certainly
helps
eliminate
a
lot
of
things
and
sadly,
docusaurus
looks
like
that
would
be
one
of
the
things
that's
eliminated.
If
we
made
that
sort
of
decision-
and
I
you
know-
I
don't
know
that
my
concern
as
an
ops
person
from
this
sort
of
thing
is-
you
know
like
I-
I
I
would
guess
that
any
of
these
things
is
going
to
take.
C
You
know
a
little
bit
of
time
to
do
this,
to
do
this
sort
of
thing
and
we
want
that
to
be
as
tight
as
cycle
as
possible,
and
you
know,
and
if
these
javascript
solutions
in
a
docker
container
can
do
this
zippier
than
I
would
guess
they
could.
Then
that's
great,
but
you
know
I
feel,
like
hugo
I've
got
more
faith,
that
it's
gonna
stand
up
to
the
performance
and
scalability
that
we
might,
you
know,
hope
to
get
to
someday.
A
Yeah
so
so
my
my
java
x
script,
experience
is
limited
to
none
and
so,
but
but
again
I
was
coming
into
an
environment
where
the
tool
set
was
already
defined
right.
The
jenkins
project,
as
I
was
began,
contributing
documentation
had
already
selected
awestruck
and
ascii
dog,
and
so
for
me
it
was
a
simple
choice.
It
had
the
benefit
that
it
didn't
put
me
into
any
oh.
I
need
to
write
javascript
to
do
extensions
it.
A
It
did
for
me
have
the
challenge
back
to
owens
point
that
it
put
me
into
a
place
where
I
have
to
write
ruby
and
I'm
a
python
programmer.
So
so
that
was
a
little
uncomfortable,
but
but
I
think
I've
actually
started
to
learn
and
adapt.
So
I
I
think,
owens
points
on
on
market
markup,
language
and
implementation.
Language
of
the
generator
are
both
valid
things
for
you
to
consider.
A
Now,
in
terms
of
in
terms
of
structuring
the
site
tracy,
how
do
you
envision
that
evolving?
Is
that
something
you
see
the
initial
is
described,
should
use
wireframes
or
is
there
some
high-level
high-level
view
of
these
are
the
kinds
of
things
we
want
to
include
already
that
that
would
might
drive
you
towards
one
solution
or
another.
F
A
A
And
and
those
kinds
of
those
kinds
of
facilities
are
there,
I
assume
that
the
the
site
most
of
the
site
generators
already
have
that
kind
of
a
concept.
Awestruck
does
it
for
us,
and
I
could
show
you
how
it
does
it,
but
I
suspect
you'll
choose
you
just
want
to
be
sure
you
evaluate
that,
whichever
side
generator
you
choose,
does
it
allow
me
to
construct
these
different
navigation
flows
through
the
site
comfortably
and
just
using
the
markdown
language
that
I'm
using
or
using
markdown,
plus
some
extension.
B
Yeah,
I
think
it's
going
to
be,
I
think,
we're
going
to
end
up
using
markdown
plus
some
kind
of
extension.
I
don't
think
markdown
alone
is
going
to
solve
the
problem.
Okay,
I
just
don't
think
it
has
a
enough
of
the
the
features
that
we're
going
to
need
now.
That
being
said,
we
might
keep
the
documentation
the
pure
documentation
and
markdown
for
now.
A
And
now,
in
terms
of
I've,
not
looked
at
how
the
markdown
systems
do
site
styling,
but
I
assume
owen
that
that
hugo
and
other
markdown
systems
allow
you
to
do
site
styling
very
comfortably.
So
they
can
fit
your
your
style
and
the
look
and
feel
that
you
want
for
the
pages
will
just
be
applied
to
all
pages
automatically.
F
F
If
you're
going
to
be
using
categories,
you
then
have
themes
which
are
basically
just
css
and
some
javascript,
and
if
you
have
a
bits
which
are
bundled
together
and
that
actually
handles
what
the
site
looks
like
the
as
with
most
static
site
generators,
what
you
can
do
is
use
the
header
information
the
front
matter
in
each
page
to
say.
Actually
this
one
is
excluded
from
this
theme
or
this
one
classes
as
a
separate
type
of
categorization.
F
So
quite
often
you
might
have
of
a
label
which
says
visa
part
of
my
doc
site,
but
this
page
is
going
to
be
an
about
page,
so
this
doesn't
get
rendered
in
that,
and
so
that
appears
on
the
menu
depending
on
the
theme.
So
there's
a
lot
of
flexibility
there.
You
can
pretty
much
create
whatever
you
want
to
in
that
regards
and
when
it
gets
rendered,
the
markdown
gets
converted
into
html.
F
As
for
all
static
site,
generators
for
themes,
replied
and
the
various
categories
you
put
through
will
get
converted
into
various
classes
within
the
css,
which
kind
of
all
ties
it
together
towards
the
end.
So
it's
a
nice
separation
in
some
ways,
because
your
content
and
how
it
renders
can
be
largely
separate
concept
concepts
outside
of
that
header
information
you
put
in
a
given
page.
So
it
allows
that
kind
of
divorce
of
concerns.
F
It
also
allows
you
to
restyle
it
quite
easily
if
you're,
finding
certain
bits
aren't
working
while
keeping
the
content
pretty
much
universal.
It's
not
quite
that
easy
in
practice,
but
that's
the
general
gist
of
how
it
should
work.
If
it
all
goes
well,
there's
always
the
odd
bit
where
a
bit
of
front
matter
needs
to
be
updated,
but
because
that's
a
structured
format.
You
can
script
that
pretty
well,
so
you
can
quite
easily
quickly
loop
over
it
and
make
additions
through
a
make
file.
For
example,.
A
And
what
owen
said
echo
is
exactly
what
the
jenkins
dot
io
pages
use.
We
have
a
front
matter
section
that
precedes
that's
at
the
top
of
each
a
doc
file.
That's
used
to
define
what
the
page
layout
is,
or
in
this
case
the
theme
or
the
style
of
that
thing.
So
we
know
when
it's
a
solution
page
or
a
tutorial
page
or
a
page
from
a
book
and
and
that
that
front
matter
is
a
great
help
to
allow
that
that
subsection
of
the
site
to
be
rendered
consistent
with
the
same
pages
in
that
subsection.
F
A
A
B
B
I've
recorded
this,
so
what
I
think
we
need
to
do
is
everybody
kind
of
think
about
what
we
you
know
what
we
discussed
today
and
I
think
next
tuesday,
is
our
general
community
meeting.
Let's
review
it,
and
if
we
want
to
pull
a
working
group
together
to
as
per
shot
suggested,
do
some
markdown
of
or
not
markdown,
but
some,
but
some
sketching
or
definition
of
what
we
want
the
site
to
look
like
and
what
are
those
particular
requirements?
We
can
do
that.