03:25:34 Rucknium: If the community is satisfied with the current system then I will, of course, need to identify a more pressing issue to which I can apply these skills. I have been an active Monero user/supporter for many years but I have not been active in the development community specifically so, at this time that is a question I would like to ask others (?) ... I can put together a t 03:25:35 horough proposal for any promising suggestions ... 03:39:47 My personal experience with the existing system wasn't good, although I accept that may have been an exception. It took 8 days to submit once I was ready and I'm familiar with Gitlab. We don't know to what extent other, less technical, potential contributors may have been put off using Gitlab in this way ... 05:34:56 FreeRoss you just struggled a bit with yaml indentation initially. Im surprised a skilled developer as yourself wasn't curious about the backend parser 05:56:38 plowsof: It may have been indentation initially, but the result of my attempt to resolve it was that the formatting defaulted to text rather than markup so that just copy/pasting yaml that we knew was correctly formatted (on your server) still wouldn't submit. To change the default formatting I had to delete the whole proposal and start again. I expected there to be nothing wrong 05:56:39 with the back end parser, as that would have impacted on other users before me, and I still don't believe there is anything wrong with it(?). The problem appeared to arise because Gitlab isn't designed specifically as a proposal submission platform, it's a general purpose technical repository for development projects (and very good for that purpose). Preventing the submission to g 05:56:41 o through due to unnecessary formatting issues would rightly be considered a bug in a system designed specifically for the purpose. There are probably good reasons why Gitlab have both options in the development context, but they would not apply in the same way for a dedicated proposal submission platform, where ease of use, including for non-technical contributores, would be a hi 05:56:43 gh priority ... 05:57:33 plowsof: It may have been indentation initially, but the result of my attempt to resolve it was that the formatting defaulted to text rather than markup so that just copy/pasting yaml that we knew was correctly formatted (on your server) still wouldn't submit. To change the default formatting I had to delete the whole proposal and start again. I expected there to be nothing wrong 05:57:35 with the back end parser, as that would have impacted on other users before me, and I still don't believe there is anything wrong with it(?). The problem appeared to arise because Gitlab isn't designed specifically as a proposal submission platform, it's a general purpose technical repository for development projects (and very good for that purpose). Preventing the submission to g 05:57:37 o through due to unnecessary formatting issues would rightly be considered a bug in a system designed specifically for the purpose. There are probably good reasons why Gitlab have both options in the development context, but they would not apply in the same way for a dedicated proposal submission platform, where ease of use, including for non-technical contributors, would be a hig 05:57:39 h priority ... 06:08:57 dsc_ wownero funding system is offline? 10:20:36 Maybe it is just me, but i think the current Gitlab interface could definitely be improved upon 10:22:30 Whether that's creating better step by step guides, fixing the little bugs that seem to keep hindering proposals, or just making it seem "easier" for those not used to a gitlab/github interface. Does MAGIC use gitlab/github? 12:54:40 what about making a basic but nice looking UI to open a new PR with the correct formatting? The UI would be a forum for the required and optional elements that is then reformatted to open the PR. That would address one of the largest gripes for less than a month of work (a week?) 12:58:34 Yeah, that would probably work 12:59:39 Especially if the platform allowed both proposal flows (UI-based one and git-like one) 14:16:52 I like that theres a bit of a hurdle / litmus test to create a ccs. GitLabs UI is just horrible and the 'git' locally method doesn't work (because of cloudflare so im told) so our proposers have to overcome adversity and be out of their comfort zone from the get-go. Im certain i could offer some useful suggestions to the manual though 14:16:52 https://ccs.getmonero.org/how-to-ccs/ e.g. you cant forl the repo from an external account.. or register for an internal one with alot of email servers so you've gotta ask on matrix/irc for manual verification.. thats just step 1. And in the latter stages 'why isnt it on the ideas page' -> i now have a runner to parse merge requests and display 14:16:52 errors 14:19:38 A webform that creates correct yaml front matter where you input milestones/amounts description for copy+pasting? 14:21:22 Im not sure how wownero does it but they have a forum involved at some stage for their funding system dsc_ 14:26:29 That's what Justin just said. 😅 14:27:20 No word on disabling the KYC when registering accounts in the gitlab instance? Asking for phone number is odd but asking for credit card information to submit, comment or react to a proposal... Hm. 14:29:58 I forgot to tag sgp_ but im half certain wowneros funding system.is that 14:30:38 what about making a basic but nice looking UI to open a new PR with the correct formatting? The UI would be a ~~forum~~ form for the required and optional elements that is then reformatted to open the PR. That would address one of the largest gripes for less than a month of work (a week?) 14:31:36 And has a 'dwetf you wanna do' license 14:33:18 plowsof https://github.com/firoorg/fcs/ 14:34:45 Their fork is also offline 14:37:21 Nah. Readme has an old link, possibly. https://funding.firo.org/ 14:38:11 https://suchwow.xyz/p/ 14:44:00 thanks! 15:44:18 plowsof: Yes, the Signaling Theory of CCS: https://en.wikipedia.org/wiki/Signalling_%28economics%29 15:45:08 Or the "no brown M&Ms" theory: https://www.snopes.com/fact-check/brown-out/ 15:45:18 > The legendary "no brown M&Ms" contract clause was indeed real, but the purported motivation for it was not. The M&Ms provision was included in Van Halen's contracts not as an act of caprice, but because it served a practical purpose: to provide a simple way of determining whether the technical specifications of the contract had been thoroughly read and complied with. 15:46:30 > So just as a little test, in the technical aspect of the rider, it would say "Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, evenly, providing nineteen amperes ..." This kind of thing. And article number 126, in the middle of nowhere, was: "There will be no brown M&M's in the backstage area, upon pain of forfeiture of the show, with full compensation." 15:46:31 >So, when I would walk backstage, if I saw a brown M&M in that bowl ... well, line-check the entire production. Guaranteed you're going to arrive at a technical error. They didn't read the contract. Guaranteed you'd run into a problem. 15:48:53 A few technical things in the current CCS software need to be fixed, but probably a whole new system isn't needed. 15:49:46 FreeRoss: You can look at some of the bounties here for idea, or even you can complete some: https://bounties.monero.social/ 15:51:33 Some people think that Haveno needs a new Desktop UI (that's in the original Haveno CCS proposal) and/or a mobile app. Either of those would be a big project. 15:53:13 People should prioritize desktop as most users of Haveno are power users or newbies that have already have a computer. I honestly don't expect people go learn to use a mobile app for trading xmr to fiat with the current UX. It needs a little bit of polishing 16:19:58 So quick update on atomic swaps / UnstoppableSwap GUI 16:19:58 There is 2+ swaps completed with success yesterday 16:19:58 I've tested UnstoppableSwap GUI and it didn't worked for me, there are some unwanted trackers 16:19:58 fonts.gstatic.com 16:19:58 api.unstoppableswap.net ( I can understand, but not really needed ) 16:19:59 My issues are related to electrum node, will make a pull to be replaced with bitcoin.stackwallet.com:50002 16:20:02 electrum_rpc_url: Url::parse("ssl://blockstream.info:700")?, 16:20:04 https://github.com/comit-network/xmr-btc-swap/blob/master/swap/src/asb/config.rs 16:20:52 swaps were completed using our asb but with real users 17:07:49 https://github.com/monero-project/meta/issues/1019 17:51:43 <123bob123:matrix.org> Pretty sure the frontend that ccs uses hasn’t been updated in 2 years 21:08:42 hopefully this PR adding a note about no conf email / 'cannt fork repo' is approved https://repo.getmonero.org/monero-project/ccs-front/-/merge_requests/40/diffs 21:09:49 I think its going to be hard. I heard the CCS coordinator was difficult to please 21:10:47 "and then and then and then" plowsof your command of the english language is terrible do better 21:11:16 literally me whenever I say literally 21:16:42 could i interest you in a monerodevs subdomain synthetic bird which pales in comparison to a getmonero one for the meta issue https://github.com/monero-project/meta/issues/1019 21:17:36 yes 21:17:40 I say yes 21:20:31 https://matrix.monero.social/_matrix/media/v1/download/monero.social/rLQKrlSMsGXEhLgoffLDeyZZ 21:21:12 oops wrong channel 22:12:00 <321bob321:monero.social> so many mirrors of monero github its a meme at this point 22:12:32 <321bob321:monero.social> requirement for ccs proposals 22:12:33 <321bob321:monero.social> 1. mirror github 22:12:35 <321bob321:monero.social> 2. run a node