These are chat archives for gitevents/core

15th
Jan 2016
Niko Nevala
@nnevala
Jan 15 2016 11:12
gitevents/gitevents-cli#7
Martin Heidegger
@martinheidegger
Jan 15 2016 12:33
Hey guys!
… Just tried to fix my readme PR ….
… by trying to read the code ...
Ian Crowther
@iancrowther
Jan 15 2016 12:34
sounds like a good place to start
Martin Heidegger
@martinheidegger
Jan 15 2016 12:34
And now I am slightly surprised at the complexity of your approach.
Or of the gitevents approach.
Ian Crowther
@iancrowther
Jan 15 2016 12:35
awsm
feedback welcome
Martin Heidegger
@martinheidegger
Jan 15 2016 12:35
So: Here is what I understand by now:
When I create an issue with the label “event” (that I can (have to?) configure) then this label will automatically create or update a json file in the repository and a milestone. The json file - in turn - seems to be used by the plugins to update the event
Is that about right?
Martin Heidegger
@martinheidegger
Jan 15 2016 12:52
Could it be that the plugins are not working atm. ?
Ian Crowther
@iancrowther
Jan 15 2016 12:53
yep
that config.json is key to the process
its got potential to be broken atm, yes
what issue do you have?
Martin Heidegger
@martinheidegger
Jan 15 2016 12:55
I am trying to find where the plugin integration happens.
https://github.com/gitevents/core/blob/master/gitevents.js#L2 constructPlugin is referenced but never used ...
Ian Crowther
@iancrowther
Jan 15 2016 12:57
hmm.. it was!
Martin Heidegger
@martinheidegger
Jan 15 2016 12:57
should be something covered by unit tests :)
Ian Crowther
@iancrowther
Jan 15 2016 12:57
my idea there was to review the config and construct the plugins
and yes, tests should have been written for sure
Martin Heidegger
@martinheidegger
Jan 15 2016 13:02
So: why is there an <event>.json file?
Ian Crowther
@iancrowther
Jan 15 2016 13:03
checking
ok so this is used by the plugins right?
config.json is to setup the pipeline
eg which plugins
api tokens etc
Martin Heidegger
@martinheidegger
Jan 15 2016 13:05
Yes, i get that.
Ian Crowther
@iancrowther
Jan 15 2016 13:05
then we parse the “issue” into event.json
that way we can easily pass it around and do “stuff"
like setup new milestones
or setup new event reg page
Martin Heidegger
@martinheidegger
Jan 15 2016 13:05
Why not “compile” this data on-the-fly
Ian Crowther
@iancrowther
Jan 15 2016 13:06
expand
you mean have each plugin parse the issue?
Martin Heidegger
@martinheidegger
Jan 15 2016 13:08
The github API is used to create the corresponding /src/events/<event>.json
https://github.com/gitevents/core/blob/master/lib/events.js#L234 but if I change the json file it will have no effect on the label issue. (its not 2way syncing, as far as I can tell).
In can see the usefulness of having this data. I just wonder why it can’t just be an API when necessary (endpoint at the server).
Or - even simpler - a plugin hook. or - yet simpler - a javascript method somewhere.
Then the user - I - would not be tempted to control events through the json data.
Ian Crowther
@iancrowther
Jan 15 2016 13:16
your correct its not 2 way
right now
you create an event issue, its does stuff
i cant recall if editing that issue updates the “stuff"
Martin Heidegger
@martinheidegger
Jan 15 2016 13:18
:)
It doesn’t, at least not in the meetup plugin.
Ian Crowther
@iancrowther
Jan 15 2016 13:18
also, if you edit labels etc, it does not sync
so right now.. its happy path
one direction
Martin Heidegger
@martinheidegger
Jan 15 2016 13:18
But… I am thinking something even different: Why not control the events and talks through markdown files in the repo rather than issues?
Ian Crowther
@iancrowther
Jan 15 2016 13:18
very early stages
well its how the meetups manage things currently
so bcn, lnug, berlinjs, nottsjs, mkjs
to name a few
i think oxfordjs do too
so its a common pattern
Martin Heidegger
@martinheidegger
Jan 15 2016 13:20
I meant like: Having issues in the source code sort-of comes with a few benefits.
Ian Crowther
@iancrowther
Jan 15 2016 13:21
"Having issues in the source code” - ? mind is twisting with that
an issue is an issue?
Martin Heidegger
@martinheidegger
Jan 15 2016 13:22
Now: Creating issue -> Creates event
New way: Creating markdown file in repo -> creates event
Ian Crowther
@iancrowther
Jan 15 2016 13:22
you mean having an issue as a markdown file
for something like metalsmith?
ok so what are the benefits?
with issues, we can add workflow like state via labels?
as the event goes from pre-event -> during-event -> post-event
Martin Heidegger
@martinheidegger
Jan 15 2016 13:24
It is still possible to have an automised workflow create milestones and labels for events.
But if the master is in the sourcecode then people can create Pull Requests on them.
(i.e. discussions on changes of events)
Ian Crowther
@iancrowther
Jan 15 2016 13:25
yep
ok so..
Martin Heidegger
@martinheidegger
Jan 15 2016 13:25
And they can trigger build scripts.
Ian Crowther
@iancrowther
Jan 15 2016 13:25
they can PR to change the date
we react..
Martin Heidegger
@martinheidegger
Jan 15 2016 13:25
i.e. It would be possible to setup a build system using “plain old build scripts"
Ian Crowther
@iancrowther
Jan 15 2016 13:25
but if you chnage the issue, we get a webhook?
and we get comments
which is less easy with a file
Martin Heidegger
@martinheidegger
Jan 15 2016 13:26
What are the comments controlling?
Ian Crowther
@iancrowther
Jan 15 2016 13:27
nothing actually
Martin Heidegger
@martinheidegger
Jan 15 2016 13:27
If the creation of the event is a Pull Request you still can make comments on the PR
Ian Crowther
@iancrowther
Jan 15 2016 13:27
is true
just shifting the discussion
hmm food for thought
Martin Heidegger
@martinheidegger
Jan 15 2016 13:27
It would make a lot more sense to me if the “data” is in the repo and the discussion is in the issue.
I see the need for a tool that automatically syncs the data to <insert-event-platform-here> but I rather have it be running on build hooks (no need for a server, travis / codeship …)
Ian Crowther
@iancrowther
Jan 15 2016 13:29
ok so we have identified two ways to approach the problem
digesting...
is a big change
trying to understand the impact, benefits etc
Martin Heidegger
@martinheidegger
Jan 15 2016 13:30
I get that mOm (japanese emoji for: I am sorry)
Ian Crowther
@iancrowther
Jan 15 2016 13:31
its healthy
and welcome
but a bomb non the less
so.. should we step back a bit here..
maybe model the “actual” processes we are trying to automate
it is easy for my and @PatrickHeneise as we work usingthe same pattern
we understand it
Martin Heidegger
@martinheidegger
Jan 15 2016 13:32
Okay.
Ian Crowther
@iancrowther
Jan 15 2016 13:33
if we can identify the “real” bottlenecks
then we can go to the tech..
any recommednations for online toos we can collab on?
shudder!
Martin Heidegger
@martinheidegger
Jan 15 2016 13:35
I assume you are using tools for the current processes?
Ian Crowther
@iancrowther
Jan 15 2016 13:35
yeah github?
@nnevala @mike182uk
you guys can jump in at any time ;-)
@alistairstead
Alistair Stead
@alistairstead
Jan 15 2016 13:36
Following along
Ian Crowther
@iancrowther
Jan 15 2016 13:37
any tools to model the processes
Alistair Stead
@alistairstead
Jan 15 2016 13:38
It seems some confusion is born from mixing where the canonical source of truth is
Ian Crowther
@iancrowther
Jan 15 2016 13:38
ok
Alistair Stead
@alistairstead
Jan 15 2016 13:38
files in the repos Vs issues in GitHub
Ian Crowther
@iancrowther
Jan 15 2016 13:39
currently its an issue
Martin Heidegger
@martinheidegger
Jan 15 2016 13:39
I am fairly clear on the status quo.
^^
Alistair Stead
@alistairstead
Jan 15 2016 13:42
@iancrowther would https://mural.ly let you visualise the workflow
Ian Crowther
@iancrowther
Jan 15 2016 13:43
looking
@martinheidegger in short, not sure atm where best to have the source of truth
we made it an issue as that was logical based on the workflow and usage of existing meetups
now im unsure if our workflow is optimum etc
and therefore its difficult to say yes or no
Ian Crowther
@iancrowther
Jan 15 2016 13:50
im going to model the processes.. but cant do it today
have biz to do
*when i murly stops glitching.. ill share so we can collab
Alistair Stead
@alistairstead
Jan 15 2016 13:54
^^ there are other tools, that just happened to be an open tab
Ian Crowther
@iancrowther
Jan 15 2016 13:54
ok
either way.. must crack on
welcome to make a start ;-)
Niko Nevala
@nnevala
Jan 15 2016 16:35
been looking at the core, thinking how to communicate with the plugins to pull out attendee list(s)
and I can see that the meetup plugin is baked right into the core, but I don't see how the tito integration happens
would it make sense to add a bit of indirection to the core and maybe use something like events to hook the plugins into the core?
Alistair Stead
@alistairstead
Jan 15 2016 16:38
If the intent is to make it extensible through plugins that would seem appropriate