-
Notifications
You must be signed in to change notification settings - Fork 333
Meeting 2016 11 25
Soon!
(Meeting moved today from 2016-11-18 due to the SocialWG face-to-face meeting being that day.)
Feel free to add to this before the meeting!
- Pump.io code development
- Adding an "Uptime service" to http://pump.io
- (If we have time) weird code in
lib/andtest/ - Security
- Security disclosures
- Security support timeframe
- Microformats2 basic support?
- Community governance and sustainability
- Node adoption (sponsoring, administering)
- Adoption of non-node related websites (e.g. OpenFarmGame, ih8.it)
- Governance (non-profit status/application)
- Funding
- Other stuff
- T-shirt designs
[22:00:17] <pumabot> #############################################################
[22:00:17] <pumabot> BEGIN LOG
[22:00:17] <pumabot> #############################################################
[22:00:18] <pumabot> Welcome to this month's Pump.io community meeting! Everyone is welcome to participate.
[22:00:18] <pumabot> This meeting is being logged and it will be posted on the wiki at https://github.com/e14n/pump.io/wiki/Meeting-2016-11-25. If you would like your nick redacted, please say so, either now or after the meeting.
[22:00:19] <pumabot> Let's start with roll call - who's here?
[22:00:19] -*- pumabot is here
[22:00:25] -*- larjona is here
[22:00:35] <xmpp-pump> ***strugee is here
[22:01:27] <clacke[m]> here
[22:02:43] <larjona> I sent email to Evan about meeting happening now, let's wait a bit
[22:02:52] <xmpp-pump> [strugee] OK
[22:12:55] <larjona> Ok, my proposal is to discuss the topics that we can
[22:13:12] <strugee> sounds good
[22:13:36] <clacke[m]> I'm just happy I finally have the time to attend a meetinf :-)
[22:14:00] <larjona> TOPIC: Pump.io code development
[22:14:00] <larjona> Adding an "Uptime service" to http://pump.io
[22:14:29] <strugee> ah
[22:14:34] <strugee> I was supposed to do something about that
[22:14:38] <strugee> but I forgot
[22:14:40] <strugee> no time
[22:14:49] <strugee> :(
[22:14:55] <larjona> Jan talked about some script with curl, maybe we can just setup that one
[22:15:15] <strugee> yeah
[22:15:35] <larjona> I can talk to him when he's online
[22:15:43] <strugee> ok
[22:15:57] <clacke[m]> is there an issue for this?
[22:16:17] <larjona> what do you mean clacke[m]? An issue in the issue tracker?
[22:16:33] <larjona> it's not something strictly related to pump.io (code)
[22:17:12] <clacke[m]> yes. If not on the code repo than maybe a dummy repo for infra issues?
[22:17:41] <strugee> we could file one in pump-io/pump.io and just put it in the "External" milestone
[22:18:06] <larjona> ok
[22:18:18] <larjona> I can file the issue later
[22:18:25] <strugee> I think Evan used to use it for that purpose, generally speaking
[22:18:33] <strugee> i.e. tracking infrastructure stuff
[22:19:09] <clacke[m]> I was mainly curious if this is closer specified somewhere. Is it uptime graphs for all servers?
[22:19:31] <strugee> yeah
[22:19:44] <larjona> no. For now, it's just a wiki or html page saying "server up" or "server down"
[22:19:54] <clacke[m]> aha
[22:19:57] <strugee> there's a bunch of discussion in last month's meeting logs but tl;dr we want something like the uptime service that jpope used to run
[22:20:08] <strugee> oh
[22:20:27] <strugee> yeah ok that makes sense
[22:21:22] <larjona> ok, so I'll file an issue, and will try to put Jan's scripts results into a wiki page in github.com/pump-io/pump.io/wiki. If somebody comes with better thing, welcome!
[22:21:27] <larjona> agree?
[22:22:44] <strugee> +1
[22:22:58] <clacke[m]> Sounds great.
[22:24:34] <pumabot> Issue #1247 "Provide a "status" wiki page or something that tracks the uptime of the different servers in the network" opened by larjona - https://github.com/pump-io/pump.io/issues/1247
[22:24:39] <larjona> I cannot find the tag "external"; I tagged it "service"
[22:24:51] <strugee> larjona: it's not a label, it's a milestone
[22:24:56] <clacke[m]> +1
[22:24:59] <larjona> ah
[22:25:29] <larjona> ok, done
[22:25:32] <strugee> larjona++
[22:25:33] <pumabot> larjona has 13 points
[22:25:55] <larjona> let's move to the next topic
[22:26:04] <larjona> TOPIC: weird code in lib/ and test/
[22:26:22] <strugee> we need Evan for that one
[22:26:27] <larjona> ok
[22:26:37] <larjona> TOPIC: Security
[22:26:41] <larjona> Security disclosures
[22:26:57] <larjona> Security support timeframe
[22:27:06] <strugee> so basically what this is about
[22:27:30] <strugee> is I think we need to have a way to disclose security vulnerabilities to the project
[22:28:23] <strugee> I was thinking we could just have a security@pump.io email address
[22:29:22] <strugee> for timeframe, that's basically how long releases have security support
[22:29:30] <larjona> I think github had a way to open an issue and keep it not public, for these kind of things
[22:29:44] <strugee> larjona: it doesn't :/
[22:29:46] <strugee> stupid GitHub
[22:30:18] <strugee> in terms of time I think 6 months for support makes sense - because of our 2-month release cycle that means that we'd support the past 3 versions with security fixes
[22:30:46] <strugee> if we ever get packaged in distributions I think it also makes sense to specifically support the versions that they package
[22:31:02] <clacke[m]> 3 versions is a lot
[22:31:28] <clacke[m]> with such a quick release cycle maybe an LTS model makes sense
[22:31:50] <clacke[m]> rather than supporting all the versions within the window
[22:33:06] <strugee> clacke[m]: I don't think so - in some projects maybe but in our case I don't think the code will change significantly enough between releases to require different patches
[22:33:30] <clacke[m]> that makes sense
[22:33:57] <clacke[m]> if support is "for free"
[22:34:24] <strugee> somewhat counter to that I'd also like to think about an LTS plan someday, but right now it doesn't make sense as we still have maintenance work that we'd like to get out the door quickly (stuff like dependency upgrades)
[22:34:58] <strugee> I don't want to commit to LTS support for a release that already includes known-outdated stuff
[22:35:16] <clacke[m]> yeah
[22:35:47] <larjona> We can think about LTS later, once we're "up to date" with dependencies etc. PRoblem is that I'm not sure we can be some day "up to date", with the quick release cycle of those projects (our dependencies) :D
[22:36:08] <clacke[m]> an LTS model for longer periods (2 years?) would make sense once things are stable
[22:36:30] <strugee> larjona: I'm not sure what you're referring to but AFAIK our deps don't release that often
[22:36:38] <strugee> or at least, they don't release semver-major changes
[22:36:50] <clacke[m]> but yeah, deps churn for node packages is pretty high
[22:37:25] <strugee> so right now we have dependencies that are a couple major versions behind
[22:37:32] <strugee> that's what I'm concerned about in terms of an LTS plan
[22:38:05] <strugee> I have no problem supporting a version where some of our dependencies continue releasing semver-minor releases
[22:38:09] <clacke[m]> it ties into what the support olans are for the dependencies
[22:39:12] <strugee> looking at the package.json I don't anticipate a lot of churn in the deps except for Express
[22:39:20] <strugee> which has decent long-term support
[22:39:24] <clacke[m]> ok, cool
[22:39:40] <strugee> Connect I think is unmaintained but I want to rip that out anyway so
[22:39:53] <larjona> But now that we're releasing each 2 months, don't we want everybody to update each two months? Why not support only the current stable version? And when we are up to date with deps, then we talk about LTS and supporting, maybe, more versions.
[22:40:32] <strugee> hmm yeah
[22:40:41] <strugee> ok how about this
[22:40:58] <strugee> we support the current release and the release before that always
[22:41:35] <strugee> if there was a semver-major release within the past 6 months, then we extend the support window to three releases back
[22:41:53] <strugee> that gives admins some extra time to migrate to the new major release
[22:42:02] <clacke[m]> if the effort is not anticipated to be high, supporting longer will help not scare away people wanting to self-host without too much investment in adminning
[22:42:40] <strugee> yeah
[22:42:43] <clacke[m]> sounds like a decent compromise
[22:42:48] <strugee> I don't think it'll be that much effort
[22:43:36] <larjona> strugee: If it's ok for you, I'm ok too. I don't see myself patching the code...
[22:43:48] <strugee> yeah, it's ok by me
[22:43:58] <strugee> so that's timeframe
[22:44:07] <strugee> we never decided on the contact method
[22:44:12] <strugee> since GitHub doesn't do private issues
[22:44:34] <clacke[m]> mail sounds straightforward
[22:44:55] <larjona> yes, but mail will get spam.
[22:45:11] <clacke[m]> who watches the mail? you two?
[22:45:28] <clacke[m]> ... or direct messages to a pump account?
[22:45:42] <strugee> I can handle the mail
[22:45:56] <strugee> since I'll almost certainly be the one fixing problems anyway
[22:45:59] <strugee> that could also work
[22:46:06] <clacke[m]> (i mean as an alternative to mail thay might get less spam)
[22:46:12] <larjona> I can handle too. I already get lots of spam for other addresses that I watch :D
[22:47:07] <strugee> ok :)
[22:47:38] <larjona> We can set "direct message to pumpio@pumpit.info or mail to security@pump.io", we cannot omit the mail address, because the pump nodes sometimes are down
[22:47:52] <clacke[m]> yes
[22:48:34] <strugee> ok sounds good
[22:48:42] <larjona> ok so shall I ask Evan for an alias, or for a mailbox?
[22:49:23] <strugee> alias I think
[22:49:53] <larjona> fine
[22:50:07] <larjona> next topic?
[22:50:20] <strugee> sure
[22:50:21] <larjona> TOPIC: Microformats2 basic support?
[22:50:28] <strugee> we need Evan for that one
[22:50:50] <larjona> ok
[22:51:12] <larjona> TOPIC: Community governance and sustainability
[22:51:12] <larjona> Node adoption (sponsoring, administering)
[22:51:30] <larjona> Did anybody get Evan's news about their adoption proposal?
[22:51:42] <larjona> Evan's news -> news from Evan
[22:51:46] <strugee> I don't think I did
[22:51:47] <larjona> Sorry my broken English
[22:52:38] <larjona> (Evan just sent apologies, he cannot attend the meeting)
[22:52:42] <clacke[m]> has he made a guess about his time plan or is it wait and see when he has the time?
[22:53:00] <clacke[m]> about adoption, I mean
[22:53:11] <larjona> He said last month he would answer the adoption requests. I guess he couldn't find the time.
[22:53:16] <strugee> ah, ok
[22:53:18] <strugee> thx larjona
[22:54:02] <larjona> ok, so I guess we cannot do more about this topic :(
[22:54:12] <strugee> :(
[22:55:41] <larjona> I'll mail Evan with a summary of the meeting including the topics that would need help from him (this one among them)
[22:55:47] <larjona> so, let's move:
[22:55:51] <larjona> TOPIC: Governance (non-profit status/application)
[22:55:59] <strugee> great
[22:56:23] <larjona> last mail from Conservancy was 2016/09/23 acknowledgeing the receipt of the application
[22:56:28] <strugee> thanks larjona!
[22:56:28] <larjona> and they said:
[22:56:39] <larjona> "We have a bit of a queue for applying projects but prioritize any projects that have a pressing need... do you have any urgent reason for increased priority in the process? "
[22:57:27] <larjona> So, my question is if I just send a ping about this, or do we add something in order to ask increased priority?
[22:58:27] <strugee> I personally don't see any reason we need increased priority
[23:00:14] <larjona> ok, so I'll send a ping, adding some updates on our project (we are in 2.x, we release each two months, etc)
[23:00:27] <larjona> TOPIC: Funding
[23:01:00] <larjona> Anything to talk about this?
[23:01:05] <larjona> (now)
[23:01:13] <strugee> I don't think so
[23:01:33] <larjona> TOPIC: T-shirt designs
[23:01:42] <strugee> oops
[23:01:44] <strugee> also me
[23:02:03] <larjona> I'm sorry strugee things are moving very quick! I guess it's not a good idea to put the version number in the t-shirts :D
[23:02:04] <strugee> maybe we should just take this off the agenda? since most of the designs are for 1.0.0...
[23:02:09] <strugee> heh
[23:02:46] <clacke[m]> :-D
[23:03:02] <larjona> My proposal is to leave this t-shirt topic frozen until we talk about funding, and sell them in our first funding campaign
[23:03:25] <strugee> heh. ok!
[23:03:29] <strugee> sounds good
[23:03:36] <larjona> ok, anything else?
[23:03:40] -*- larjona goes for the cake
[23:04:44] <larjona> so recently it was my birthday
[23:04:47] <larjona>
[23:04:47] <larjona> , , ,
[23:04:47] <larjona> 1__1__1
[23:04:47] <larjona> {
@@@}
[23:04:47] <larjona> {. . . . . .}
[23:04:47] <larjona> {___________}
[23:04:47] <larjona>
[23:05:09] <strugee> happy birthday larjona!!
[23:05:18] <strugee> \o/
[23:05:23] <clacke[m]> happy birthday!
[23:06:39] <larjona> ok, let's finish the meeting?
[23:06:42] <clacke[m]> feliz cumpleaños!
[23:06:46] <larjona> thanks
[23:07:08] <larjona> pumabot: end meeting
[23:07:08] <pumabot> Thank you all for attending! Logs will be posted on the wiki shortly at https://github.com/e14n/pump.io/wiki/Meeting-2016-11-25.
[23:07:09] <pumabot> Also, special thanks to larjona for chairing!
[23:07:09] <pumabot> See you next month!
[23:07:09] <pumabot> #############################################################
[23:07:09] <pumabot> END LOG
[23:07:09] <pumabot> #############################################################
[22:00:17] <pumabot> #############################################################
[22:00:17] <pumabot> BEGIN LOG
[22:00:17] <pumabot> #############################################################
[22:00:18] <pumabot> Welcome to this month's Pump.io community meeting! Everyone is welcome to participate.
[22:00:18] <pumabot> This meeting is being logged and it will be posted on the wiki at https://github.com/e14n/pump.io/wiki/Meeting-2016-11-25. If you would like your nick redacted, please say so, either now or after the meeting.
[22:00:19] <pumabot> Let's start with roll call - who's here?
[22:00:19] -*- pumabot is here
[22:00:25] -*- larjona is here
[22:00:35] <xmpp-pump> ***strugee is here
[22:01:27] <clacke[m]> here
[22:02:43] <larjona> I sent email to Evan about meeting happening now, let's wait a bit
[22:02:52] <xmpp-pump> [strugee] OK
[22:12:55] <larjona> Ok, my proposal is to discuss the topics that we can
[22:13:12] <strugee> sounds good
[22:13:36] <clacke[m]> I'm just happy I finally have the time to attend a meetinf :-)
[22:14:00] <larjona> TOPIC: Pump.io code development
[22:14:00] <larjona> Adding an "Uptime service" to http://pump.io
[22:14:29] <strugee> ah
[22:14:34] <strugee> I was supposed to do something about that
[22:14:38] <strugee> but I forgot
[22:14:40] <strugee> no time
[22:14:49] <strugee> :(
[22:14:55] <larjona> Jan talked about some script with curl, maybe we can just setup that one
[22:15:15] <strugee> yeah
[22:15:35] <larjona> I can talk to him when he's online
[22:15:43] <strugee> ok
[22:15:57] <clacke[m]> is there an issue for this?
[22:16:17] <larjona> what do you mean clacke[m]? An issue in the issue tracker?
[22:16:33] <larjona> it's not something strictly related to pump.io (code)
[22:17:12] <clacke[m]> yes. If not on the code repo than maybe a dummy repo for infra issues?
[22:17:41] <strugee> we could file one in pump-io/pump.io and just put it in the "External" milestone
[22:18:06] <larjona> ok
[22:18:18] <larjona> I can file the issue later
[22:18:25] <strugee> I think Evan used to use it for that purpose, generally speaking
[22:18:33] <strugee> i.e. tracking infrastructure stuff
[22:19:09] <clacke[m]> I was mainly curious if this is closer specified somewhere. Is it uptime graphs for all servers?
[22:19:31] <strugee> yeah
[22:19:44] <larjona> no. For now, it's just a wiki or html page saying "server up" or "server down"
[22:19:54] <clacke[m]> aha
[22:19:57] <strugee> there's a bunch of discussion in last month's meeting logs but tl;dr we want something like the uptime service that jpope used to run
[22:20:08] <strugee> oh
[22:20:27] <strugee> yeah ok that makes sense
[22:21:22] <larjona> ok, so I'll file an issue, and will try to put Jan's scripts results into a wiki page in github.com/pump-io/pump.io/wiki. If somebody comes with better thing, welcome!
[22:21:27] <larjona> agree?
[22:22:44] <strugee> +1
[22:22:58] <clacke[m]> Sounds great.
[22:24:34] <pumabot> Issue #1247 "Provide a "status" wiki page or something that tracks the uptime of the different servers in the network" opened by larjona - https://github.com/pump-io/pump.io/issues/1247
[22:24:39] <larjona> I cannot find the tag "external"; I tagged it "service"
[22:24:51] <strugee> larjona: it's not a label, it's a milestone
[22:24:56] <clacke[m]> +1
[22:24:59] <larjona> ah
[22:25:29] <larjona> ok, done
[22:25:32] <strugee> larjona++
[22:25:33] <pumabot> larjona has 13 points
[22:25:55] <larjona> let's move to the next topic
[22:26:04] <larjona> TOPIC: weird code in lib/ and test/
[22:26:22] <strugee> we need Evan for that one
[22:26:27] <larjona> ok
[22:26:37] <larjona> TOPIC: Security
[22:26:41] <larjona> Security disclosures
[22:26:57] <larjona> Security support timeframe
[22:27:06] <strugee> so basically what this is about
[22:27:30] <strugee> is I think we need to have a way to disclose security vulnerabilities to the project
[22:28:23] <strugee> I was thinking we could just have a security@pump.io email address
[22:29:22] <strugee> for timeframe, that's basically how long releases have security support
[22:29:30] <larjona> I think github had a way to open an issue and keep it not public, for these kind of things
[22:29:44] <strugee> larjona: it doesn't :/
[22:29:46] <strugee> stupid GitHub
[22:30:18] <strugee> in terms of time I think 6 months for support makes sense - because of our 2-month release cycle that means that we'd support the past 3 versions with security fixes
[22:30:46] <strugee> if we ever get packaged in distributions I think it also makes sense to specifically support the versions that they package
[22:31:02] <clacke[m]> 3 versions is a lot
[22:31:28] <clacke[m]> with such a quick release cycle maybe an LTS model makes sense
[22:31:50] <clacke[m]> rather than supporting all the versions within the window
[22:33:06] <strugee> clacke[m]: I don't think so - in some projects maybe but in our case I don't think the code will change significantly enough between releases to require different patches
[22:33:30] <clacke[m]> that makes sense
[22:33:57] <clacke[m]> if support is "for free"
[22:34:24] <strugee> somewhat counter to that I'd also like to think about an LTS plan someday, but right now it doesn't make sense as we still have maintenance work that we'd like to get out the door quickly (stuff like dependency upgrades)
[22:34:58] <strugee> I don't want to commit to LTS support for a release that already includes known-outdated stuff
[22:35:16] <clacke[m]> yeah
[22:35:47] <larjona> We can think about LTS later, once we're "up to date" with dependencies etc. PRoblem is that I'm not sure we can be some day "up to date", with the quick release cycle of those projects (our dependencies) :D
[22:36:08] <clacke[m]> an LTS model for longer periods (2 years?) would make sense once things are stable
[22:36:30] <strugee> larjona: I'm not sure what you're referring to but AFAIK our deps don't release that often
[22:36:38] <strugee> or at least, they don't release semver-major changes
[22:36:50] <clacke[m]> but yeah, deps churn for node packages is pretty high
[22:37:25] <strugee> so right now we have dependencies that are a couple major versions behind
[22:37:32] <strugee> that's what I'm concerned about in terms of an LTS plan
[22:38:05] <strugee> I have no problem supporting a version where some of our dependencies continue releasing semver-minor releases
[22:38:09] <clacke[m]> it ties into what the support olans are for the dependencies
[22:39:12] <strugee> looking at the package.json I don't anticipate a lot of churn in the deps except for Express
[22:39:20] <strugee> which has decent long-term support
[22:39:24] <clacke[m]> ok, cool
[22:39:40] <strugee> Connect I think is unmaintained but I want to rip that out anyway so
[22:39:53] <larjona> But now that we're releasing each 2 months, don't we want everybody to update each two months? Why not support only the current stable version? And when we are up to date with deps, then we talk about LTS and supporting, maybe, more versions.
[22:40:32] <strugee> hmm yeah
[22:40:41] <strugee> ok how about this
[22:40:58] <strugee> we support the current release and the release before that always
[22:41:35] <strugee> *if* there was a semver-major release within the past 6 months, then we extend the support window to three releases back
[22:41:53] <strugee> that gives admins some extra time to migrate to the new major release
[22:42:02] <clacke[m]> if the effort is not anticipated to be high, supporting longer will help not scare away people wanting to self-host without too much investment in adminning
[22:42:40] <strugee> yeah
[22:42:43] <clacke[m]> sounds like a decent compromise
[22:42:48] <strugee> I don't *think* it'll be that much effort
[22:43:36] <larjona> strugee: If it's ok for you, I'm ok too. I don't see myself patching the code...
[22:43:48] <strugee> yeah, it's ok by me
[22:43:58] <strugee> so that's timeframe
[22:44:07] <strugee> we never decided on the contact method
[22:44:12] <strugee> since GitHub doesn't do private issues
[22:44:34] <clacke[m]> mail sounds straightforward
[22:44:55] <larjona> yes, but mail will get spam.
[22:45:11] <clacke[m]> who watches the mail? you two?
[22:45:28] <clacke[m]> ... or direct messages to a pump account?
[22:45:42] <strugee> I can handle the mail
[22:45:56] <strugee> since I'll almost certainly be the one fixing problems anyway
[22:45:59] <strugee> that could also work
[22:46:06] <clacke[m]> (i mean as an alternative to mail thay might get less spam)
[22:46:12] <larjona> I can handle too. I already get lots of spam for other addresses that I watch :D
[22:47:07] <strugee> ok :)
[22:47:38] <larjona> We can set "direct message to pumpio@pumpit.info or mail to security@pump.io", we cannot omit the mail address, because the pump nodes sometimes are down
[22:47:52] <clacke[m]> yes
[22:48:34] <strugee> ok sounds good
[22:48:42] <larjona> ok so shall I ask Evan for an alias, or for a mailbox?
[22:49:23] <strugee> alias I think
[22:49:53] <larjona> fine
[22:50:07] <larjona> next topic?
[22:50:20] <strugee> sure
[22:50:21] <larjona> TOPIC: Microformats2 basic support?
[22:50:28] <strugee> we need Evan for that one
[22:50:50] <larjona> ok
[22:51:12] <larjona> TOPIC: Community governance and sustainability
[22:51:12] <larjona> Node adoption (sponsoring, administering)
[22:51:30] <larjona> Did anybody get Evan's news about their adoption proposal?
[22:51:42] <larjona> Evan's news -> news from Evan
[22:51:46] <strugee> I don't think I did
[22:51:47] <larjona> Sorry my broken English
[22:52:38] <larjona> (Evan just sent apologies, he cannot attend the meeting)
[22:52:42] <clacke[m]> has he made a guess about his time plan or is it wait and see when he has the time?
[22:53:00] <clacke[m]> about adoption, I mean
[22:53:11] <larjona> He said last month he would answer the adoption requests. I guess he couldn't find the time.
[22:53:16] <strugee> ah, ok
[22:53:18] <strugee> thx larjona
[22:54:02] <larjona> ok, so I guess we cannot do more about this topic :(
[22:54:12] <strugee> :(
[22:55:41] <larjona> I'll mail Evan with a summary of the meeting including the topics that would need help from him (this one among them)
[22:55:47] <larjona> so, let's move:
[22:55:51] <larjona> TOPIC: Governance (non-profit status/application)
[22:55:59] <strugee> great
[22:56:23] <larjona> last mail from Conservancy was 2016/09/23 acknowledgeing the receipt of the application
[22:56:28] <strugee> thanks larjona!
[22:56:28] <larjona> and they said:
[22:56:39] <larjona> "We have a bit of a queue for applying projects but prioritize any projects that have a pressing need... do you have any urgent reason for increased priority in the process? "
[22:57:27] <larjona> So, my question is if I just send a ping about this, or do we add something in order to ask increased priority?
[22:58:27] <strugee> I personally don't see any reason we need increased priority
[23:00:14] <larjona> ok, so I'll send a ping, adding some updates on our project (we are in 2.x, we release each two months, etc)
[23:00:27] <larjona> TOPIC: Funding
[23:01:00] <larjona> Anything to talk about this?
[23:01:05] <larjona> (now)
[23:01:13] <strugee> I don't think so
[23:01:33] <larjona> TOPIC: T-shirt designs
[23:01:42] <strugee> oops
[23:01:44] <strugee> also me
[23:02:03] <larjona> I'm sorry strugee things are moving very quick! I guess it's not a good idea to put the version number in the t-shirts :D
[23:02:04] <strugee> maybe we should just take this off the agenda? since most of the designs are for 1.0.0...
[23:02:09] <strugee> heh
[23:02:46] <clacke[m]> :-D
[23:03:02] <larjona> My proposal is to leave this t-shirt topic frozen until we talk about funding, and sell them in our first funding campaign
[23:03:25] <strugee> heh. ok!
[23:03:29] <strugee> sounds good
[23:03:36] <larjona> ok, anything else?
[23:03:40] -*- larjona goes for the cake
[23:04:44] <larjona> so recently it was my birthday
[23:04:47] <larjona>
[23:04:47] <larjona> , , ,
[23:04:47] <larjona> __1__1__1__
[23:04:47] <larjona> {~@~ ~@~ ~@~}
[23:04:47] <larjona> {. . . . . .}
[23:04:47] <larjona> {___________}
[23:04:47] <larjona>
[23:05:09] <strugee> happy birthday larjona!!
[23:05:18] <strugee> \o/
[23:05:23] <clacke[m]> happy birthday!
[23:06:39] <larjona> ok, let's finish the meeting?
[23:06:42] <clacke[m]> feliz cumpleaños!
[23:06:46] <larjona> thanks
[23:07:08] <larjona> pumabot: end meeting
[23:07:08] <pumabot> Thank you all for attending! Logs will be posted on the wiki shortly at https://github.com/e14n/pump.io/wiki/Meeting-2016-11-25.
[23:07:09] <pumabot> Also, special thanks to larjona for chairing!
[23:07:09] <pumabot> See you next month!
[23:07:09] <pumabot> #############################################################
[23:07:09] <pumabot> END LOG
[23:07:09] <pumabot> #############################################################