<f​reeross:monero.social> 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<clipped message>

<f​reeross:monero.social> horough proposal for any promising suggestions ...

<f​reeross:monero.social> 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 ...

FreeRoss you just struggled a bit with yaml indentation initially. Im surprised a skilled developer as yourself wasn't curious about the backend parser

<f​reeross:monero.social> 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 <clipped message>

<f​reeross:monero.social> 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<clipped message>

<f​reeross:monero.social> 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<clipped message>

<f​reeross:monero.social> gh priority ...

<f​reeross:monero.social> 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 <clipped message>

<f​reeross:monero.social> 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<clipped message>

<f​reeross:monero.social> 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<clipped message>

<f​reeross:monero.social> h priority ...

dsc_ wownero funding system is offline?

Maybe it is just me, but i think the current Gitlab interface could definitely be improved upon

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?

<s​gp_:monero.social> 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?)

Yeah, that would probably work

Especially if the platform allowed both proposal flows (UI-based one and git-like one)

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

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

errors

A webform that creates correct yaml front matter where you input milestones/amounts description for copy+pasting?

Im not sure how wownero does it but they have a forum involved at some stage for their funding system dsc_

<r​ottenwheel:kernal.eu> That's what Justin just said. 😅

<r​ottenwheel:kernal.eu> 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.

I forgot to tag sgp_ but im half certain wowneros funding system.is that

<s​gp_:monero.social> what about making a basic but nice looking UI to open a new PR with the correct formatting? The UI would be a <del>forum</del> 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?)

And has a 'dwetf you wanna do' license

<r​ottenwheel:kernal.eu> plowsof github.com/firoorg/fcs

Their fork is also offline

<r​ottenwheel:kernal.eu> Nah. Readme has an old link, possibly. funding.firo.org

<r​ottenwheel:kernal.eu> suchwow.xyz/p

thanks!

<r​ucknium:monero.social> plowsof: Yes, the Signaling Theory of CCS: en.wikipedia.org/wiki/Signalling_%28economics%29

<r​ucknium:monero.social> Or the "no brown M&Ms" theory: snopes.com/fact-check/brown-out

<r​ucknium:monero.social> > 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.

<r​ucknium:monero.social> > 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."

<r​ucknium:monero.social> >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.

<r​ucknium:monero.social> A few technical things in the current CCS software need to be fixed, but probably a whole new system isn't needed.

<r​ucknium:monero.social> FreeRoss: You can look at some of the bounties here for idea, or even you can complete some: bounties.monero.social

<r​ucknium:monero.social> 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.

<s​yntheticbird:monero.social> 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

So quick update on atomic swaps / UnstoppableSwap GUI

There is 2+ swaps completed with success yesterday

I've tested UnstoppableSwap GUI and it didn't worked for me, there are some unwanted trackers

fonts.gstatic.com

api.unstoppableswap.net ( I can understand, but not really needed )

My issues are related to electrum node, will make a pull to be replaced with bitcoin.stackwallet.com:50002

electrum_rpc_url: Url::parse("ssl://blockstream.info:700")?,

swaps were completed using our asb but with real users

<s​yntheticbird:monero.social> monero-project/meta #1019

<1​23bob123:matrix.org> Pretty sure the frontend that ccs uses hasn’t been updated in 2 years

hopefully this PR adding a note about no conf email / 'cannt fork repo' is approved repo.getmonero.org/monero-project/ccs-front/-/merge_requests/40/diffs

<s​yntheticbird:monero.social> I think its going to be hard. I heard the CCS coordinator was difficult to please

"and then and then and then" plowsof your command of the english language is terrible do better

<s​yntheticbird:monero.social> literally me whenever I say literally

could i interest you in a monerodevs subdomain synthetic bird which pales in comparison to a getmonero one for the meta issue monero-project/meta #1019

<s​yntheticbird:monero.social> yes

<s​yntheticbird:monero.social> I say yes

<s​yntheticbird:monero.social> matrix.monero.social/_matrix/media/…ero.social/rLQKrlSMsGXEhLgoffLDeyZZ

oops wrong channel

<3​21bob321:monero.social> so many mirrors of monero github its a meme at this point

<3​21bob321:monero.social> requirement for ccs proposals

<3​21bob321:monero.social> 1. mirror github

<3​21bob321:monero.social> 2. run a node