├── CHARTER.md ├── Proposal-workflow.md ├── README.md ├── minutes ├── 2022-01-17.md ├── 2022-08-30.md ├── 2022-09-06.md ├── 2022-09-13.md ├── 2022-09-20.md ├── 2022-09-27.md ├── 2022-10-04.md ├── 2022-10-11.md ├── 2022-10-18.md ├── 2022-11-01.md ├── 2022-11-08.md ├── 2022-11-15.md ├── 2022-12-13.md ├── 2023-01-24.md ├── 2023-02-07.md ├── 2023-02-21.md ├── 2023-03-07.md ├── 2023-03-14.md ├── 2023-03-21.md ├── 2023-03-28.md ├── 2023-04-04.md ├── 2023-04-11.md ├── 2023-04-18.md ├── 2023-05-23.md ├── 2023-05-30.md ├── 2023-06-06.md └── 2023-06-13.md ├── proposal-template.md └── wip └── well-architected-framework └── README.md /CHARTER.md: -------------------------------------------------------------------------------- 1 | Development Experience Working Group Charter 2 | 3 | 4 | The Development Experience Working Group Charter establishes the Scope, intellectual property terms used to develop the materials identified and details the related requirements and operational processes important for the Working Group’s operation. 5 | 6 | 7 | 1. Working Group Name: Development Experience Working Group 8 | 9 | 10 | 2. Meeting Cadence: Weekly on Tuesdays 4:30-5:15 pm BST 11 | 12 | 13 | 3. Working Group Aim 14 | 15 | 16 | The aim of this working group is to identify and develop strategies to improve the overall developer experience across the cardano ecosystem. Specifically targeting developers working against Cardano Layer 1. 17 | 18 | 19 | 3.1 Scope 20 | 21 | 22 | * Layer 1 smart contract & offchain component tooling 23 | * Enhancement CIPs directed the Cardano Ledger, Plutus, CBOR formats, or Metadata 24 | * Should include nontechnical components such as educational materials, github issue handling, and high-fidelity communications 25 | * Cross-language approaches to interacting with cardano (python, js, golang) 26 | 27 | 28 | 4. Operations and duties 29 | 30 | 4.1 Working Group Responsibilities 31 | 32 | The working group works to: 33 | * Identify and document known themes and issues which create friction in the adoption and industrial use of Plutus and Cardano 34 | * Documentation and research for CIPs and Internally Proposed efforts from inception to implementation 35 | * Engaging in and planning quantatative and qualatative research to help prioritize work 36 | * Solicitation of sponsorship for projects from various Ecosystem actors 37 | * Creation of a public (github, live meetings) forum for the discussion of these issues and projects 38 | 39 | 4.2 Initial Working Group Members 40 | 41 | 42 | Positions and names to be agreed and confirmed in the coming sessions as the group is currently being formed 43 | 44 | 45 | Chairpersons: 46 | * Ben Hart 47 | * Alex TODO 48 | * Phillip DiSarro 49 | 50 | 4.3 Chair Selection 51 | 52 | * Chairs shall be volunteers or elected by the members (in the event of a contest), with no more than four chairs serving at one time. Service shall be evaluated annually, with no maximum term. 53 | * The Chair/s of the working group will rotate every six months to ensure equal participation from all members of the working group. 54 | 55 | 4.4 Chair Duties 56 | 57 | * Driving inclusivity, identifying consensus within the group, and recording decisions. 58 | * Ensuring compliance with the rules and principles established in this document. 59 | * Being a liaison between the group and all groups with which the group is coordinating. 60 | * Organizing the smooth operation of the group. 61 | 62 | 4.5 New members 63 | 64 | 65 | This is a community-led initiative so we encourage members of the Cardano community who want to improve the overall developer experience across the cardano ecosystem to join the Developer Experience Working Group start by joining the Discord Channel 66 | 67 | 68 | Join our discord server (use this link), and verify to participate in the group: 69 | https://discord.gg/MrFSKDMRvm 70 | 71 | 5. Communications 72 | Members of the Developer Experience Working Group are committed to a high standard of public behavior and strive to treat every person with respect. 73 | 74 | 6. Decision Making 75 | Consensus/Voting/Approval. Each Working Group will endeavor to make all decisions by consensus. Where the Working Group cannot reach consensus with respect to a particular decision, the Developer Experience Working Group will make that decision by a supermajority vote of the Working Group Participants, as applicable. 76 | 77 | 7. Process 78 | The repository is designed to simplify and consolidate GitHub status tracking of work items managed by the Developer Experience Working Group. 79 | 80 | The working group uses the GitHub workflow as it's primary mechanism for discussion and for decision making 81 | 82 | Issues/Proposals can have the following statuses 83 | - Issue - Identifies an issue which may have no clear solution - but can be identified as an area of research for the working group. (these can take the form of github issues with labels for priority) 84 | - Draft - Seeks to solve a Discussion issue with a concrete proposal which is technologically feasible (if applicable). This may be a place where developers wishlist features of a proposed solution. (These will take the form of a pull request) 85 | - Accepted - the proposal describes a sound solution to a statistically significant problem. A proposal is deemed Accepted when the working group agrees to merge a proposal into the main branch of the repository. 86 | - Seeking Sponsorship/Action - The working group is actively soliciting sponsors or other actors to provide the solution described. Accepted proposals will either be accepted with an active sponsor, or the group will actively seek sponsorship for unsponsored, accepted proposals. A sponsor may include a large actor in the ecosystem or a small individual developer. 87 | 88 | 8. Success Criteria 89 | 90 | * Identified issues result in change 91 | * TODO 92 | 93 | 94 | 9. Funding 95 | This working group has no direct funding. 96 | 97 | 10. Copyright Policy. 98 | all work within this repository unless otherwise noted is under GNU public license. 99 | individual proposers may include copyright for their specific proposal. 100 | 101 | 11. Non-Working Group Participant Feedback and Participation. 102 | 103 | 104 | The Developer Experience Working Group can request feedback from and/or allow Non-Working Group Participant participation in the Developer Experience Working Group subject to each Non-Working Group Participant agreeing to the below Feedback Agreement. 105 | 106 | 107 | 12. Feedback agreement 108 | 109 | 110 | The Developer Experience Working Group wants to improve the overall developer experience across the cardano ecosystem. 111 | The Developer Experience Working Group would like to receive input, suggestions and other feedback (“Feedback”) on the Materials. By participating on this Working group, you (on behalf of yourself if you are an individual and your company if you are providing Feedback on behalf of the company) grant the Development Experience Working Group all applicable intellectual property rights owned or controlled by you or your company a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, publish, license, modify, sublicense or otherwise distribute and exploit Feedback you provide for the purpose of developing and promoting the Materials and in connection with any product that implements and complies with the Materials. You warrant to the best of your knowledge that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that the Development Experience Working group is not required to incorporate your Feedback into any version of the Materials. 112 | You further agree that you and your company will not disclose it or distribute drafts of the non-public Development Experience Working Group Materials to third parties. Unless the parties agree otherwise or the Development Experience working group Materials are made publicly available by the Development Experience Working Group, this obligation of non-disclosure will expire five (5) years from the date the material was disclosed to you. 113 | -------------------------------------------------------------------------------- /Proposal-workflow.md: -------------------------------------------------------------------------------- 1 | # Proposal And Decision Workflow 2 | 3 | Preamble: While the developer experience working group is organizing itself, we need a means of making decisions. 4 | As the group grows, these mechanisms may be adjusted. 5 | 6 | As the Developer experience git repository is the public facing aspect of the group, merge's should happen during or immediately after group meetings and reflect agreements made there. 7 | 8 | Currently the meeting recurrs every week on Tuesday at 16:00 UTC - if there are 4 or more developer-participants at that group and the chair, and there is 60% or greater approval among attendees that a proposal or pull request status should be adjusted, then the status can be updated on git. However in general the group will seek to work from consensus. 9 | 10 | Proposals can have the following statuses 11 | - Discussion - Identifies an issue which may have no clear solution - but can be identified as an area of research for the working group. (these can take the form of github issues with labels for priority) 12 | - Draft - Seeks to solve a Discussion issue with a concrete proposal which is technologically feasible (if applicable). This may be a place where developers wishlist features of a proposed solution. 13 | - Accepted - the proposal describes a sound solution to a statistically significant problem 14 | - Seeking Sponsorship/Action - The working group is actively soliciting sponsors or other actors to provide the solution described. 15 | 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Developer-Experience-Working-Group 2 | 3 | Welcome to the Cardano Developer Experience Working Group. 4 | 5 | ## What does the developer experience working group do? 6 | 7 | We're a community-driven group dedicated to identifying and presenting potential solutions to developer experience problems that span the Cardano ecosystem. Once a potential solution is identified, we work with actors in the ecosystem to find sponsorship to implement a solution. 8 | 9 | We meet every Tuesday at 3:30PM/15h30m UTC. 10 | 11 | We also use Github for discussions and the IOHK Developer Discord. 12 | 13 | ## What kind of issues fall under developer experience? 14 | - Key barriers to adopting or being productive when developing against Cardano, as either offchain statistics or onchain dApp 15 | - Missing/Inadequate tooling or key workflow issues when composing tools to build an end-to-end dApp 16 | - Documentation 17 | - multi-language/multi-ecosystem tie-in (What are the added problems when building on Mobile, embedded systems, Unity/C#, Python or javascript ecosystems) 18 | - Best practices and default dApp architectures. 19 | 20 | ## How can I get involved? 21 | 22 | Do you have a concern relating to developer experience working on Cardano? Check our [issues](https://github.com/input-output-hk/Developer-Experience-working-group/issues) page and contribute to a discussion, or file a new issue. 23 | 24 | To join the [Developer Working group Discord Channel](https://discord.gg/9zPhXfdF9A) 25 | 26 | ## How do we use this github repository? 27 | 28 | This repository houses the [Charter](CHARTER.md), which defines how the group operates and makes decisions. We also have the [minutes](minutes) folder which houses text records of each Tuesday meeting, arranged by date. 29 | 30 | Most discussion topics will take the form of Github issues and pull requests. 31 | Issues describe a given problem facing the Cardano developer ecosystem, or a desired change to how the group is run. 32 | PR's propose solutions, identify individuals or organizations which can and will execute the solution. Once a solution has a clear path to execution, the proposal will be merged to the main branch of the repository. 33 | 34 | All merges require at least 1 review, merge rights are handled by the co-chairs. 35 | 36 | 37 | -------------------------------------------------------------------------------- /minutes/2022-01-17.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer experience working group 2022/01/17 2 | 3 | ## Attendance 4 | alexeusgr 5 | AndrewWestberg 6 | Anita Jovic 7 | Fayyaadh 8 | Hans Lahe 9 | Ignacio 10 | James Dunseith 11 | Jonathan777 12 | Philip DiSarro 13 | Santiago [TxPipe] 14 | Sebastian Pabon 15 | Simon Thompson 16 | Steve Lockhart 17 | waalge 18 | Whatever [SIDAN] 19 | WoodlandPools 20 | 21 | ## Minutes 22 | 1. Agenda setting 23 | - Ben: well we have some changes to Charter & Readme 24 | - Alex: Simon, would it be useful to have a discussion about fuzzing or mutation testing. 25 | - Simon: Perhaps we should have Romain join for next week - he leads the certification program now. 26 | 27 | 2. Charter & ReadMe Revisions 28 | Ben: I've posted a revision to the readme & charter - please leave a negative review if you disagree, otherwise we'll likely merge later this week 29 | 30 | - Also we've resolved some logjams in our merge workflow, we should get a bunch of minutes merged soon 31 | 32 | - Ignacio - Can the co-chairs get access to post the agenda on discord please? 33 | Ignacio: I'll add it to my todo 34 | 35 | 3. Scaling & Batching Solutions 36 | - Andrew: What was the deal with MLabs scaling project? 37 | - Ben: It's a project called 'Seath' Internally, it's essentially a sidechain where the sidechain nodes operate a batcher. 38 | 39 | 40 | 4. Plutus & Nix 41 | - waalge: when is the next plutus pioneers? 42 | - Simon: unknown at the moment, but we are working with Plank Labs and they are writing a tutorial. 43 | - waalge: I am also hitting a lot of barriers with Nix 44 | - Philip: Demeter.run can really help, there are also some good haskell-specific nix tutorials 45 | - Ben: I recommend nix-pills and the haskell.nix manual, but it's still quite incomplete. 46 | - Philip: Would people be interested in having docker-for-everything? IOG used to maintain a docker image for plutus, maybe we should revive it. 47 | 48 | -------------------------------------------------------------------------------- /minutes/2022-08-30.md: -------------------------------------------------------------------------------- 1 | # Development Experience Working group - Tuesday, August 30, 2022 2 | 3 | 4 | Agenda 5 | 6 | 7 | * Github procedures 8 | * Community engagement and developer feedback 9 | 10 | 11 | Minutes 12 | 13 | 14 | * Github procedures and rights to merge. This is a community-led initiative therefore the community should have these rights. As new members join this working group this will be decided 15 | * Issues will lead to Pull-requests in the Github workflow. 16 | * Ideally the initial drafts should be written in markdown in github as a branch for transparency and visibility to all the members. However it was mentioned that on some occasions developers prefer to work together in a google doc for a couple days and then put it as a single markdown file when it is in its final stage and before it gets accepted. The idea is to keep the workflow as simple as possible for the users. If a side group of developers wants to work on a document they can add the link to initial issue so people are aware that they are working on a proposal and put it as PR at the final stages 17 | * For visibility and to gather feedback from other members of the community, the community and ecosystem team will help launch a developer experience digest where some of the outputs from the working group will be shared. This is an initial ideal and needs to be refined. 18 | * It was clear that until we don't have more participants and actual proposals are being written down the above is just a draft idea. 19 | * The processes will be clearly defined as more people are engaged and we learn from the process. 20 | * Priorizacion, voting, etc… are examples of key points that will be defined in due time. 21 | * Minutes & actions will be published in Github so if people missed one meeting they know what was discussed and up to date. 22 | * Proposals are the key purpose of this working group so it would be interesting to understand how the developer experience has changed for beginners over time. Understanding this will help identify where the gaps are. 23 | * Community and Ecosystem team proposed different alternatives to help developers that this group could maybe support 24 | * Mentoring/ buddy partner for a couple of weeks 25 | * Ask questions to the community for this group to pick and publish in digest 26 | * Community and Ecosystem team and Wave joined the call as they are helping to engage with more developers to join the developer experience working group 27 | 28 | 29 | Actions: 30 | 31 | 32 | IOG - to work on a Developer experience working group Digest plan . This is still in the early stages. The proposed plan will be shared in due time when more developers join and proposals can be shared. 33 | IOG - prepare interview questions to understand current developer experience. What tools they use, blockers, issues, where they use as a source for documentation…. The objective is to discover the technical engineering part. Draft version to be shared in Discord for the members to share feedback 34 | IOG/ Wave - to engage with developers to collaborate in the working group. 35 | IOG - Publish draft/ example of the charter document in github. This will be an example/ proposal for the working group to update, define and agree. 36 | Community - to start adding proposals. 37 | 38 | 39 | Updates as of 2nd September 2022 40 | 41 | 42 | Wave and IO are reaching out to developers to invite them to collaborate with this initiative. Some new members from the community will join on Tuesday. 43 | Next week’s meeting will start 30 min later. Andrew Sutherland and Ger Moroney will join the meeting to share their views on how we can collaborate together. -------------------------------------------------------------------------------- /minutes/2022-09-06.md: -------------------------------------------------------------------------------- 1 | # Development Experience Working group - Tuesday, Sept 6 2022 2 | 3 | ## Agenda: 4 | 5 | 1. Ger Maroney & Andrew Sutherland - DevExp Working Group Purpose 6 | 2. developer survey from @francolq 7 | 3. proposals review 8 | 4. decision making framework 9 | 5. Can IOG provide any existing intelligence or statistics? 10 | 11 | ## Minutes 12 | 13 | 1. Gerard Maroney & Andrew Sutherland - DevExp Working Group Purpose 14 | Gerard: 15 | - After Vasil's release, we (IOG) need to get better at hearing the community. 16 | - We'd like to have stronger communication with the community where the community can write down and help prioritize issues 17 | - IOG cannot pay for all work across the board, but we are willing to work together to find solutions, co-operate with other actors, and work with developers and catalyst to see these issues addressed. 18 | 19 | Andrew: 20 | - Previous meetups and dialogues have been very rewarding, 21 | - we need a scalable way to gather feedback and priorities around pain-points 22 | 23 | Simon: 24 | - this can be an opportunity to avoid duplication of effort (such as chain-index replacements) 25 | - find tools created at individual companies and make the solutions general 26 | 27 | Johnny: 28 | - Sounds like we are at a point of surfacing and putting all of the issues on the table so that we can get our arms around the challenges, opportunities and priorities. 29 | 30 | 2. developer survey from @francolq 31 | Anusheel: 32 | - Plank labs has developed a questionnaire which we could use for initial understanding of the ecosystem and which tools are being used in production. 33 | Johnny: 34 | - What are the goals? are there hypotheses you want to test? 35 | Santiago: 36 | - it removes our survivorship and other biases 37 | 38 | survey is editable at https://docs.google.com/document/d/1-pQKy5kQ-S2cp9Ry5OXHkzuq3kiJqOifaNa1UOh_AYw/edit?usp=sharing 39 | 40 | the following agenda items were tabled for next week due to time considerations: 41 | 3. proposals review 42 | 43 | 4. decision making framework 44 | 45 | 5. Can IOG provide any existing intelligence or statistics? 46 | 47 | -------------------------------------------------------------------------------- /minutes/2022-09-13.md: -------------------------------------------------------------------------------- 1 | 2 | # Minutes for Tues, Sept 13 3 | 4 | Attendees: 5 | - Adriana Saez 6 | - Andrew Sutherland 7 | - Santiago Carmuega 8 | - Dominka Kopec 9 | - Cody Butz 10 | - Ernesto Copello 11 | - Aric Chang 12 | 13 | Minutes: 14 | 1. Charter update & minutes 15 | - Charter update is PR 11 - it can be merged by end of day unless anyone raises objections/PR comments 16 | - going forward minutes should be merged from PR at the meeting following the one they cover 17 | 2. Andrew - Plutus Team current priorities 18 | over the coming 6 months, our main priorities cover: 19 | plutus-core: 20 | - SECP256K1 & Bitwise Primops 21 | - script-context parsing and how to avoid it 22 | - integrating plutonomy as a compilation step 23 | plutus-apps/tools 24 | - debugger (some discussion around Untyped Plutus Core + Sourcemaps vs PlutusTx only solution) 25 | - onchain script failure mechanisms 26 | - script testing two ways - onchain, offchain/scalable 27 | 28 | -------------------------------------------------------------------------------- /minutes/2022-09-20.md: -------------------------------------------------------------------------------- 1 | # Minutes for Tues, Sept 20 2 | 3 | Attendance 4 | plutus developer community: 5 | Ben Hart (MLabs) 6 | Cody Butz (Indigo) 7 | Deniz Delkilic (Paribus) 8 | interested parties: 9 | Adriana Saez (IOG) 10 | Andrew Sutherland (IOG) 11 | Aric Chang (Wave/CFund) 12 | Dominika Kopec (IOG) 13 | Hans Lahe (IOG) 14 | Simon Thompson (IOG) 15 | Ziyang Liu (IOG) 16 | 17 | Minutes: 18 | 19 | 1. Debugger 20 | - Andrew: Ziyang Liu is working on the debugger 21 | - Ziyang: We're currently planning the first product increment, and deciding between GHCI-based approach or PlutusCore+Sourcemaps approach 22 | - Ben: GHCI would be wonderful - there aren't many tools that give you this tight of a feeback loop and it could really increase developer productivity in plutus - however the semantic differences when executing plutus code vs plutusTx-as-haskell may cause some serious troubles with this approach. 23 | - Ziyang: MPJ and others on the plutus team share this concern. 24 | 25 | 2. Readme adjustments to repo 26 | - Ben: I created a readme with key points simplified from the Charter, please add any PR comments by end of day or we'll presume this is ready for merge. 27 | - (some additional discussion around the Charter and some outstanding points on it, as well as discord access steps, and the possibility of moving to a similar discord model as the CIP editor group). 28 | 29 | 3. Next week's chairperson 30 | - Ben: I am unavailable to chair next week's meeting as i'm travelling, i will be able to attend but it is probably better if someone else prepares the agenda and runs the meeting, perhaps we can invite Planck Labs to chair next week? 31 | (Adriana to follow up) 32 | 33 | 4. CIP subcommittee 34 | - Andrew: Does it make sense to have a subcommittee facing the current CIPs 35 | - Ben: I think it does, perhaps this can be something we grow as we gain active members, 36 | - Adriana: Lets start with identifying a list of our top 5 CIPs relating to developer experience? 37 | 38 | 5. Survey and Invitations 39 | - Ignacio - the survey has gone out to a list of developers, respondants will also be invited to join this group. 40 | -------------------------------------------------------------------------------- /minutes/2022-09-27.md: -------------------------------------------------------------------------------- 1 | # Minutes for Sept 27 2022 2 | 3 | Attendance 4 | Developer community: 5 | Anusheel Bhushan (Plank) 6 | Ben Hart (MLabs) 7 | Colin Hobbins (Lode) 8 | Santiago Carmuega (TxPipe) 9 | 10 | Interested parties: 11 | Addie Girouard (IOG) 12 | Adriana Saez (IOG) 13 | Aric Chang (CFund) 14 | Dominika Kopec (IOG) 15 | Hans Lahe (IOG) 16 | Ignacio Calderon (IOG) 17 | Johnny Nguyen (DCF/IOG) 18 | Simon Thompson (IOG) 19 | Ziyang Liu (IOG) 20 | 21 | Minutes: 22 | 23 | 1. Update on DevExp Working group Survey 24 | - Anusheel: we have sent the survey to 12 recipients, 4 of which have responded 25 | - Ben: can we get a larger samples size? 26 | - Anusheel: yes, Ignacio is coordinating 27 | - Ben: great, i'll get some contacts to Ignacio and coordinate from there 28 | 29 | 2. 'State of Cardano' Survey 30 | - Johnny: the sentiment is quite favorable overall 31 | - Ben: Yes, but there may be some ways methodology or sample distribution mislead us here 32 | - Ignacio: only about 25% of respondants are professional developers, this includes many hobbyists or non-developers 33 | - Simon: Can we ask for the dataset? 34 | - Ben: It's actually open sourced already 35 | - Simon & Ignacio agree that it is worthwhile to look at filtered data sets to see if new insights can be found 36 | 37 | 3. Next steps on listed proposals/issues & Concrete action planning 38 | - Ben: I have a lot of issues i'd like to fill in, and i should even have some time to get to some of them this week. I can commit to: Multi-lang support listing, E2E example dApps, Documentation, and Layer 1 scaling and thruput for dApps as some issues i can get started this week. 39 | - Colin: It would be great to have some Coordination among Wallets, dApp developers and toolmakers for some critical infra, especially networks availability. Maybe a short writeup about the differences between the testnets as well. 40 | - Ben: That would really help in the way of formalizing expectations around existing developer-facing infra. The https://book.world.dev.cardano.org/environments.html resource really needs to be publicized 41 | - Simon: The relevant technical writer is currently on leave. 42 | 43 | Discussion ended with Ben, Colin and Santiago each committing to at least 1 issue - this way even if one of us gets sidelined, we can have a meaningful conversation at the next DEWG meeting. 44 | 45 | 46 | -------------------------------------------------------------------------------- /minutes/2022-10-04.md: -------------------------------------------------------------------------------- 1 | # Minutes for October 4th, 2022 2 | 3 | Attendance 4 | Developers: 5 | - Ben Hart, Mlabs 6 | - Santiago Carmuega, TxPipe 7 | - Cody Butz, Indigo 8 | - Colin Hobbins, Lode Wallet 9 | Interested Parties: 10 | - Addie Girouard, IOG 11 | - Adriana Saez, IOG 12 | - Andrew Sutherland, IOG 13 | - Anita Jovic, IOG 14 | - Carlos Lopez de Lara, IOG 15 | - Hans Lahe, IOG 16 | - Ignacio Calderon de la Barça, IOG 17 | - Johnny Nguyen, IOG/DCF 18 | - Simon Thompson, IOG 19 | - Ziyang Liu, IOG 20 | 21 | ## 1. Carlos Lopez de Lara - Cardano CLI + API 22 | - transactions should be easier to build using new features added to CLI + Cardano API 23 | - What are the features that are needed by developers? 24 | - Ben: happy to volunteer some MLabs developers for a focus group 25 | 26 | ## 2. Hardfork Retrospective @ IOG 27 | - Simon: there is an ongoing internal process to refine how we do Hard Fork events 28 | - What went well, what could have been better, how could things be improved, what should we keep doing. 29 | - Ben: the new testnets are great, the naming scheme could be clarified a great deal, the fact that the HF process required two epoch boundaries could have been better communicated. 30 | - Simon: please contact me on the discord with additional notes. 31 | 32 | ## 3. Top CIPs 33 | - Ben: I've compiled a list of the Cips which both currently exist AND require change in either plutus or the ledger - and picked out the ones that we think could have the best impact on developer experience over Plutus v3 and v4 34 | - Andrew: consider CIP 38 as an addition to the list 35 | - Simon: Is the CIP process fit for purpose? 36 | - Colin: It would be nice if there was clearer handoff between the CIP editors and the implementors. 37 | - Ben: Very open to additional CIPs being added to this list here is the issue:https://github.com/input-output-hk/Developer-Experience-working-group/issues/20 38 | 39 | ## 4. Multilang support 40 | - Ben: I've compiled a list of the known API's for either creating a plutus smart contract or for preparing offchain transactions across programming languages: https://github.com/input-output-hk/Developer-Experience-working-group/issues/21 41 | - Colin: 1-1 mappings of tools between Ethereum + Cardano would be really helpful 42 | - Shruti: this is really useful and can help us to drive adoption. 43 | - Ben: I want to underscore that to drive adoption we may want to provide tools with sourcemapping and documentation where the user can choose the example lanaguage. 44 | - Johnny: a good example of documentation for multi languages: https://www.algolia.com/developers/ 45 | -------------------------------------------------------------------------------- /minutes/2022-10-11.md: -------------------------------------------------------------------------------- 1 | ## Minutes for Tues, Oct 11, 2022 2 | 3 | **Attendees:** 4 | 5 | * Santiago Carmuega (TxPipe) 6 | * Cody Butz (Indigo) 7 | * Colin Hobbins (Obsidian Systems) 8 | * Deniz Dalkilic (Paribus) 9 | * Zhao Tan (Fourier Labs) 10 | * Jack Ho (Fourier Labs) 11 | * Charles Augu (Smart Chain) 12 | 13 | **Interested parties:** 14 | 15 | * Andrew Sutherland - IOG 16 | * Simon Thompson - IOG 17 | * Dominika Kopec (IOG) 18 | * Hans Lahe (IOG) 19 | * Simon Thompson (IOG) 20 | * Johnny Nguyen (IOG) 21 | * Ziyang Liu (IOG) 22 | * Joseph Fajen (IOG) 23 | * Anita Jovic (IOG) 24 | * Ignacio Calderon de la Barca (IOG) 25 | * Shruti Appiah (IOG) 26 | * Adriana Saez - IOG 27 | 28 | **Apologies:** 29 | 30 | * Ben Harts (Mlabs) 31 | * Interested party - Aric Chang (Wave Financials) 32 | 33 | **Minutes:** 34 | 35 | * **Cardano Well-Architected Framework #28** 36 | 37 | It’s been proposed to build a well-documented framework with best practices on how to approach the development regarding security, performance, reliability, monitoring, tracing, all of those disciplines in a single place that developers can use as guidelines when approaching a new project. It should be a description on how to architect the project from different perspectives. 38 | 39 | Some internal work is being done at IOG and feedback for the community is very important as to what is the prioritization for these different aspects? for example, Cardano API, should be the primary public entry point, interface to the Cardano technology for Haskell developers. Are we referring to something very Haskell specific around Cardano API or something more at the level of REST interface or web back end? 40 | 41 | Two different frameworks are needed. 42 | 43 | **Canonical SDK framework:** for Haskell developers to interact with the Cardano technology, 44 | 45 | **Agnostic technology framework,** which this issue refers to, provides concepts and best practices, regardless of the programming language used (Haskell or otherwise). This would be a higher level than the Canonical SDK framework, more of a system architect, rather than a smart contract or off-chain component developer. 46 | 47 | A lot of articles, documentation exist about best practices, the key here is to have a framework. There is a lot to learn from how the cloud providers approach these problems.. 48 | 49 | Having an organized framework provides system architects something more concrete to work with, that can be updated and improved as things move along and best practices arise from community or IOG. 50 | 51 | Some kind of level of authority is needed to define the best practices. 52 | 53 | As a starting point it was proposed to run an architecture workshop between IOG and people from the community to present their view on what a well architecture on Cardano looks like. 54 | 55 | Discussion to create a wiki was mentioned with different opinions within the working group. More thought needs to be put on. 56 | 57 | It was suggested to include the IOG education team into these calls so questions like, is this a training onboarding (education)? or is this really technical documentation for smart contracts? 58 | 59 | It was highlighted that this framework should be broader than smart contracts, there is a lot of focus on best practices, education for on-chain components, and there is a lot happening outside that needs to be looked at. The user would be more for a system architect 60 | 61 | How can this be done in a useful way without reference apps? The full stack is very important as otherwise these things are siloed. A reason on how they connect to the rest of the project is necessary. The idea could be the use of a canonical reference app that could be used to create the different links and gradually become more general - IOG is working on some initial documentation proposals that Andrew will share with the working groups before building anything. 62 | 63 | However, the idea of the new framework refers to how to organize the different components agnostic from the language and tools being used. There is an intermediate step between the reference app and the development guidelines for best practices. 64 | 65 | A risk was raised as external parties who are opinionated, will be using Catalyst to fund the development of their stack, so to create a framework that shows that you don't actually need to use their stack it is ok; It's just eventually incentives may get a little bit tricky. 66 | 67 | * **Evaluate node-to-client communication via TCP #27** 68 | 69 | The node-to-client protocols are only available through Unix sockets. 70 | 71 | The rationale behind this solution is not known so the assumption is that it has to do with security concerns so the node-to-client protocols are not exposed to the network. 72 | 73 | It will be really useful in certain scenarios, to be able to access the node-to-client protocols from the TCP stack and not be constrained by the node to be running the consumer within the same Unix namespace as the node. 74 | 75 | Why is this built this way? Understanding the rationale would be useful so a decision on the solution can be made if there is a missing part. 76 | 77 | This is more a networking level or even a Cardano node architecture level question. This needs to be followed with the right team. 78 | 79 | As a workaround, many teams use the socket as a way to bypass the limitation but it has its downsides (connectivity, etc..). If we could have direct access through TCP, deployment will be much simpler. 80 | 81 | This is interesting as it relates to the previous item, and the need of the framework. (How do you do scaling, off-balancing, how do you connect...) 82 | 83 | Ziyang is also very supportive of this solution so as an internal champion within Plutus can try to push it. 84 | 85 | For the moment there are more than 600 requests in the backlog, so no need to raise a new ticket. Also it was noted that IO is working on defining a process to build the pipeline, start triaging these issues and escalating the ones that are really a priority considering the community feedback and that is why this forum is very important. 86 | 87 | For the moment the conversations on this matter will be followed in this request. 88 | 89 | * **Ouroboros mini-protocols full specification #26** 90 | 91 | There is very useful and complete documentation regarding the state machines around ouroboros mini protocols, but they are generic over implementations of the ledger. Some parts of the protocol data models are not defined by the specs 92 | 93 | Users have been trying to extract from the codebase the missing parts but it is difficult, as these are distributed scattered through many source files so the users cannot be sure if it is the latest version or not. 94 | 95 | This is a request to extend the current specs to describe not only the ouroboros mini protocols from the generic perspective but also in its concrete implementation for the Cardano ledger. 96 | 97 | This is important and certainly useful for IO so it is a matter of prioritizing internally 98 | 99 | This example (https://arsmagna.xyz/docs/network-lsq/) was reviewed and suggested to be pursued by the community. 100 | 101 | Andrew’s views were that this is a case of reverse engineering the code which is a terrible way to write documentation. However it could be a useful way to produce the creation of this documentation. 102 | 103 | IO protocols experts should review this, and contribute to the “wiki” to make sure the information is accurate. This could be an interesting collaboration model between the community and IO experts 104 | 105 | **Actions:** 106 | 107 | * Adriana - Share recording within internal IOG stakeholders to show the importance of these meetings and specially the 3 requests made. 108 | * Adriana - find internal resources as representatives from the node. 109 | 110 | Cardano Well-Architected Framework #28 111 | 112 | * Invite a member of the IOG education team 113 | * Santiago/ Ignacio - to browse through the frameworks, extract some structure regarding what topics they touch and how they approach them and update the proposal 114 | * All - start to define what are the broadest technical requirements or functional requirements that the solution would need to be able to support 115 | 116 | Evaluate node-to-client communication via TCP #27 117 | 118 | * Follow-up internally (networking level or Cardano node architecture teams) to understand the rationale of the solution and comment in github 119 | * Ziyang to follow-up with Marconi architecture 120 | 121 | Ouroboros mini-protocols full specification #26 122 | 123 | * https://arsmagna.xyz/docs/network-lsq/ to be reviewed internally by SME and contribute. 124 | * Adriana - research internally and find out how this proposal could be progressed. 125 | -------------------------------------------------------------------------------- /minutes/2022-10-18.md: -------------------------------------------------------------------------------- 1 | ## Minutes for Tues, Oct 18, 2022 2 | 3 | **Attendees:** 4 | 5 | * Ben Harts (Mlabs) 6 | * Santiago Carmuega (TxPipe) 7 | * Colin Hobbins (Obsidian Systems) 8 | * Zhao Tan (Fourier Labs) 9 | * Jack Ho (Fourier Labs) 10 | * Charles Augu (Smart Chain) 11 | * Quinn P 12 | 13 | **Interested parties:** 14 | 15 | * Dominika Kopec (IOG) 16 | * Konstantinos Lambrou (IOG) 17 | * Johnny Nguyen (IOG) 18 | * Ziyang Liu (IOG) 19 | * Joseph Fajen (IOG) 20 | * Anita Jovic (IOG) 21 | * Ignacio Calderon de la Barca (IOG) 22 | * Adriana Saez - (IOG) 23 | 24 | **Apologies:** 25 | 26 | * Cody Butz (Indigo) 27 | * Deniz Dalkilic (Paribus) 28 | * Interested party - Andrew Sutherland (IOG) 29 | * Interested party - Simon Thompson (IOG) 30 | * Interested party - Hans Lahe (IOG) 31 | * Interested party -Shruti Appiah (IOG) 32 | * Interested party - Aric Chang (Wave Financials) 33 | 34 | **Minutes:** 35 | 36 | * **Charter** - No comments have been made on Charter therefore we are in a position to merge. 37 | 38 | * **Agenda** will be shared in advance. Not all IOG resources are needed in the weekly meeting so going forward agenda will be shared in advance so relevant IOG resources can decide if attendance is required. 39 | 40 | * **API** breakage and compatibility resource. #25 41 | 42 | Different suggestion have been made: 43 | 44 | Having a built machine that can check any new commit on master for today's apps, or tools that are outside of iOS preview too. A build machine that goes and checks which versions of Plutus will be built. So it offers a new commit on master which commits along the master branch it will build with from Plutus, meaning running eight or 10 builds back so users can see within a reasonable range, who is going to have to upgrade Plutus in order to use this. 45 | 46 | A further step could be taken, documenting the API changes and in some cases where they can be automated, automating the way. Something like GHC to actually look at the ASDs, find where the API breakages occur and automatically fix them or at least, as the user upgrades have that document surfaced to the developer that there is an API breakage and some recommendations about how to fix it. 47 | 48 | API changes it's one of the main pain points as a developer and having some straightforward way to understand them, get notified and read about them makes a lot of sense. 49 | 50 | The solution proposed goes beyond having a change log (this presumes that the developer has gone back and tested against all previous builds). Often building compatibilities are almost implicit. Usually the Plutus apps will bump to a new version of Plutus and it is not always clear which previous versions it will be built with. 51 | 52 | The goal is to have a source of truth where people can look at all of the Cardano facing IOG & ecosystem tooling. 53 | 54 | It was added that wherever this is done a readme section should be added providing a kind of hand holding for junior developers teaching them about the interplay between this and CI or whatever the case is. 55 | 56 | The proposal is about limiting API breakage or making it clear when an API breaks. Often, the breakages have clear solutions and where possible it is worthwhile to find ways to automate those solutions, or surface them to the user more easily. 57 | 58 | More details regarding the proposed solution in terms of automating breakages needs to be added into the issue. Initial solution could be: 59 | 60 | Mechanisms such as live GHC that you can use to look for these API breakages used in the individual code base, and update them automatically. 61 | Having a resource where the user can see that there was a recent update across the ecosystem that informs the user of changes in the particular API breakage. 62 | 63 | Change logs are not doing a great job surfacing those API breakages and some projects are not even tracking a change log. Tie the projects with a Readme 64 | 65 | The emphasis is on a single source of truth where everything is listed and the use for each of the tools listed. 66 | 67 | It was proposed to keep track of which GHC versions the individual tools will build with as there is no clear direction on what to expect there or its interplay with the other things. It was proposed that having a CI CD job ensuring that compatibility is maintained with certain GHC versions could be the way. Getting clarity about **GHC next versions, and the compatibility story** will be raised as a separate issue. 68 | 69 | It was agreed that more quantitative evidence is needed. Different efforts have been discussed that would relieve some of these issues. Agreed to move this discussion into a proposal and seek out champions to help bringing this into the world 70 | 71 | It was discussed the option to write a new **CIP regarding Off-chain tools**, what are the standards to define them. 72 | 73 | Off-chain tool is anything that doesn't run on-chain. Any tool that needs to interact with the chain, execute processes, work with data and not be a smart contract could potentially be called an off-chain component so it’s hard to provide a strict definition. However, the PAB would fall under this category and requires some contextualization. Therefore to give a strict definition, some alternatives and usage in a framework has value. 74 | 75 | This will be approached as part of the Cardano Well-Architected Framework #28 defining best practices rather than a CIP 76 | 77 | As part of this issue it was discussed that it might be useful to explore a taxonomy first. Having a taxonomy for the different components and types of applications will be interesting to have. A lot of what has been discussed already exists in different places. More case studies or examples would be helpful. 78 | We have https://jan-bernatik.medium.com/introduction-to-flow-blockchain-7532977c8af8 however there is a little of https://developers.flow.com/learn/kitty-items . 79 | 80 | It was agreed to keep working on the Cardano Well-Architected Framework #28 81 | 82 | A more broad discussion of **tools that fall outside of transaction building and architecture** will be analyzed by Ben. How do you actually orchestrate these tools together to build a Dapp? How do you remix these tools? 83 | 84 | Joseph is interested in collaborating with the group on gathering high level topics to start delineating some documentation of a process. How do we describe the overall process of Dapp creation? Collaborating and playing the role of maintaining/ outlining documentation, resources. 85 | There is a high need for this. 86 | 87 | * **End-to-end testing for wallets (on disposable testnets)** was explained. This refers to end to end testing, including a front end on a reproducible test net. 88 | 89 | The biggest barrier as far as having reproducible arbitrary test nets is that the developer could run in CI and test things not properly. A wallet needs to enable arbitrary block frosts URLs, as well as arbitrary nodes. 90 | A health scape testnet with exactly the same parameters and model as Mainnet that is just congested and miserable so developers can use it for battle test new product launch. 91 | 92 | The dream solution would be a debug capability similar to what truffle does in the solidity world. As a developer it is really important to have a reproducible testnet that can be set-up real quick and then just shut it down. 93 | 94 | Cardano Testnet is in the Cardano node repo. This is Mainnet behavior where the developer provides the protocol parameters needed. 95 | https://github.com/input-output-hk/cardano-node/tree/master/cardano-testnet 96 | 97 | * A new issue was presented to **make the protocol parameters available from the HTTP service** to have tools that can easily query a set of protocol parameters that will match Mainnet or Testnet. 98 | 99 | **Actions:** 100 | 101 | * Ben - To add more details regarding the proposed solution in terms of automating breakages needs to be added into the issue. 102 | * Ben & Colin to raise an issue regarding GHC 9.2. GHC next versions, and the compatibility story 103 | * Ben & Joseph to coordinate that there are not duplicated efforts 104 | Transaction building - Santiago is going to lead this champion through the well architected framework part. 105 | * Ben - To look at categorizing other types of tools. There are around four or five distinct types of tools, but there's actually multiple tools emerging and competing over certain pieces of that. 106 | * Ben to raise a new issue regarding making the protocol parameters available from the HTTP service 107 | * Invite David Arnold who has been maintaining & building the Cardano world repo to a meeting to provide a better understanding of the Cardano world. 108 | -------------------------------------------------------------------------------- /minutes/2022-11-01.md: -------------------------------------------------------------------------------- 1 | # Minutes for Tues, 2022-11-01 2 | 3 | ## Attendance: 4 | IOG: 5 | Adriana Saez 6 | Andrew Sutherland 7 | David Arnold 8 | Hans Lahe 9 | Johnny Nguyen 10 | Joseph Fajen 11 | Michael Peyton Jones (MPJ) 12 | Simon Thompson 13 | Ziyang Liu 14 | 15 | Developer community: 16 | Ben Hart (MLabs) 17 | Charles Augu (Cardashift) 18 | Colin Hobbins (Obsidian/Lode) 19 | Santiago Carmuega (TxPipe) 20 | Zhao Tan 21 | 22 | ## Minutes: 23 | 24 | 1. Long term GHC support - MPJ 25 | - currently moving to support 9.2 26 | - will create a public policy about migrations 27 | - no long term backwards compatibility support for older compilers 28 | - for a compiler version to be considered, we need to know that there are not show-stopper bugs against Windows or other less-supported platforms 29 | - The ecosystem also needs to catch up to a given compiler version such that we can feasibly move to it without forking dependencies. 30 | 31 | Ben: How can you issue a deprecation warning that 8.10 support is going away? 32 | MPJ: We don't really have a release process or official channel for this 33 | People need to be able to read them and know that they exist 34 | Perhaps we can establish something working with the group in this meeting. 35 | Something standard like github releases would be nice because it has an RSS feed. 36 | 37 | Ben: Perhaps we can make some recommendations for channels over the coming weeks 38 | MPJ: That would be welcome, Also we are working on making our work friendlier to outside open source contributions, including Contributing docs, etc. 39 | 40 | Santiago: automating changelogs from commit messages can be really helpful when making sure changelogs get written 41 | 42 | 43 | 2. Cardano World - David Arnold 44 | - (Code tour of nix code) 45 | - David: Cardano World represents a compedium of A) Documentation and B) nix derivations to run and deploy working testnets 46 | - Ben: It would be great to know what will be included in the future documentation 47 | - David: Right now it's largely limited to protocol parameters and cost models 48 | 49 | 3. Congested Testnet - Ben 50 | Ben: we have a new proposal for a congested testnet following on from Colin's suggestion at the last meeting. MLabs intends to propose it to Catalyst fund 10. 51 | Andrew: How much of this is new development? 52 | Ben: only the simulation aspect 53 | Colin: I believe Andrew from DripDropz has some capabilities for automated hammering 54 | Ben: If you could look into it and add it either to the PR or original issue that would be really helpful. The main goal is to try to get this group some kind of early success story as a model for others. 55 | 56 | 4. Other business: Cryptographic Primitives 57 | Tan: I'm particularly interested in the BLS Pairing functions, since they are vital for Zero-Knowledge Proofs. 58 | Andrew: There are some concerns with those. They will likely be worked on during 2023, however we're not quite sure if some of these primitives can fit within our cost restrictions, additionally we have a finite number of primitive operations we can add and so we need to be careful as we select them. 59 | Ben: it would be most useful early on if you can pick out specific functions from those cips and make a comment on them about which functions are most critical to your usecase. There may also be a possible saving grace in the Bitwise Primops feature which we are hoping will land early next year. 60 | -------------------------------------------------------------------------------- /minutes/2022-11-08.md: -------------------------------------------------------------------------------- 1 | # Minutes for November 8, 2022 2 | 3 | Attendance 4 | Developers: 5 | Ben Hart 6 | Santiago Carmuega 7 | Colin Hobbins 8 | 9 | IOG: 10 | Adriana Saez 11 | Anita Jovic 12 | Andrew Sutherland 13 | Hans Lahe 14 | Joseph Fajen 15 | Ziang Liu 16 | 17 | Minutes 18 | 19 | - Additional chairpeople 20 | Ben Hart: we would really like to fill out the roster of co-chairpeople on this working group - let me know if you're interested in contributing more and we can find a good division of labor that suits your ability to contribute. 21 | 22 | - documentation issue 23 | Ben Hart: I have created a small list of documentation wishlists based on a survey I ran. There are about 4 key issues so far, but perhaps this can be a running wishlist and other developer teams can add to it. 24 | Ziang Liu: Perhaps narrowing the target audience a bit? there are often high-level articles or some docs in the spec. 25 | Joseph: Perhaps more specificity about what the developer might be trying to do as examples so that we can understand what information would be most critical for each of these. 26 | 27 | - deprecation notices 28 | Ben Hart: following on from last week's visit from MPJ - i've made some high level recommendations for channels 29 | Ziang Liu: really changelogs should be on here as well 30 | Ben Hart: those were purposely omitted because MPJ said that changelogs aren't being written 31 | Ziang: Well this needs to change. We should be writing them, Deprecation pragmas is one option, if we have deprecation pragmas and changelogs that should be sufficient 32 | Santiago: I should mention that in the previous meeting i was not recommending any particular tool for building a changelog from commit messages, just to build it as a practice within the team and to adopt the tool of your choice. 33 | Ben: Ziang, I see you were also asking about Beta API's - i think you can send custom type errors or warnings for this usecase 34 | 35 | - Next week's agenda 36 | 37 | - Next steps on existing tickets, issue tagging scheme 38 | - focus: Well architected framework 39 | - dApp Testing w/ Simon Thompson 40 | 41 | -------------------------------------------------------------------------------- /minutes/2022-11-15.md: -------------------------------------------------------------------------------- 1 | # Minutes for Tuesday, Nov 15, 2022 2 | 3 | Attendance: 4 | Developer community: 5 | Ben Hart - Mlabs 6 | 'alexusgr' 7 | Andrew WestBerg - DripDropz 8 | Antony Burrows - L3Labs 9 | Colin Hobbins - Lode Wallet 10 | James Dunseith 11 | JHO 12 | Jingles 13 | ManiaKugel 14 | Santiago Carmuega - TxPipe 15 | Sebastian Pabon 16 | Shibu 17 | szist 18 | Tan 19 | whitevo 20 | Maksymilian Brodowicz - Optim/MLabs 21 | 22 | IOG: 23 | Simon Thompson 24 | Adriana Saez 25 | Anita Jovic 26 | Ignacio Calderon de le Barca 27 | 28 | 29 | Minutes: 30 | 31 | - Next steps on existing tickets, issue tagging scheme 32 | note: there were many newcomers here, Ben provides a high level overview of how the working group documents issues and proposals) 33 | Ben: Over the weekend i went through some standing issues and added a number of next-steps for each item, is there anything in particular we'd like to look at the well-architected framework item. 34 | (with no items for specific discussion, we move to the next agenda item) 35 | 36 | - focus: Well architected framework 37 | Maksymilian: Can we get a high-level Intro to the topic? 38 | Ben: So the goal is to provide a set of solutions to resolve many of the most common engineering problems across _most_ protocols. What would next steps for this look like? is it more of a documentation project or is it going to require a serious codebase? 39 | Santiago: I think it will be mainly documentation 40 | Simon: Perhaps this could be a subcommittee 41 | Maksymilian: and run it through the CIP process. 42 | Simon: Or it could be owned by this group 43 | James volunteered to work on such a subcommittee 44 | Santiago: Perhaps this can be an ongoing project, the table of contents likely needs to be expanded. 45 | Ben: Unfortuntately I will need to run, if the meeting wishes to continue i'll just ask for someont to please update the minutes that i'll be making a pull request for. 46 | 47 | (notes from discord - credit: Shibu) 48 | -I understand it is a part Best practice documentation and code snippet project 49 | People involved need to be familiar with build dApps on Cardano to recommend Best Practices 50 | A subgroup of 3-5 people will be better to prioritize tasks and assign each to the members 51 | 52 | 53 | - New items for discussion 54 | 55 | - Next week's agenda (to include testing with Simon) 56 | 57 | -------------------------------------------------------------------------------- /minutes/2022-12-13.md: -------------------------------------------------------------------------------- 1 | # Minutes for Dec 13, 2022 2 | 3 | # attendance 4 | 5 | Alexeusgr 6 | ASaezIOG 7 | asutherlandus 8 | BenHart-mlabs 9 | Colin Hobbins 10 | Hans Lahe 11 | Igodlab 12 | Jingles 13 | jamesdunseith-gimbalabs 14 | Matthias [LOXE] 15 | Nyk 16 | Phillip DiSarro 17 | Santiago [TxPipe] 18 | Sebastian Pabon 19 | Simon Thompson 20 | Skywalker 21 | Steve Lockhart 22 | szist 23 | waalge 24 | 25 | 26 | # Minutes: 27 | 28 | 1. Well-architected framework 29 | 30 | - James: This project will open up a lot of critical information for cardano developers, we have created a draft outline around several key priorities: Reliability, Security, Cost Optimization, Performance, Decentralization, Scalability, UX/UI 31 | - Nyk: Consider including Documentation as a Pillar. Would be great if documentation included minimal examples around API usage. 32 | - Alexeusgr: Could you provide a good and bad example of documentation 33 | - James: One way to check if a new pillar belongs on the list is: could you fill out a set of principles, best practices, and reference implementations. 34 | - Nyk: I'll either send it to you or send a PR to Santiago's fork of the repo. 35 | - Santiago: What if we expand the scope of 'documentation' to a broader mission of 'maintainability', which may include versioning, change management, etc. 36 | - Nyk: Maintainability is somewhat more internally focused - i would seperate it because it faces external users, rather than something that can be adopted as an internal development team. 37 | - James: Anything else feel like it it may be missing 38 | - Simon: Testing likely belongs here, and recommended tooling may spin out of that 39 | - Nyk: Testing feels like it's cross-cutting across the other pillars, ie 'Reliability Testing, Performance testing, etc. 40 | - James: It's OK to have some redundancy at least in the early drafts. What about the three subheadings 41 | - Ben: I would suggest 'further reading or related articles' 42 | - James: That sounds reasonable. 43 | - Simon: Once this is complete - we need to think about maintenance and/or versioning. 44 | - Santiago: the goal here is to keep things at the 'best practice' level, so hopefully we won't go out of date as easily as a software dependency. 45 | - James: I've added some notes in my local version about versioning and change management. 46 | - James: For next steps - I'll push some changes based on this conversation. 47 | 48 | 49 | 2. Repository Workflow 50 | - Ben: Happy to discuss this, though the original intent and systems we built into the charter were really just enough to get us to the current point. The goal is that each co-chair would have merge rights and that all PR's would require at least 1 review. I don't have a strong opinion about the Well-architected framework being in our repo or in an external one. 51 | - Igodlab: How can we make sure the process is clear to people from the repo? How can a user contribute or volunteer, and find the discord from the github repo & vice-versa? 52 | - Phillip: We also need some level of community engagement - otherwise people will burn out and there will be no incentive for others to contribute. This could be a Hackathon, or some community Twitter Event. Something to incentivice actual contribution. 53 | - James: I agree - this ought to be incentivised work. 54 | - Igodlab: Perhaps other platforms should receive updates & visibility when we make progress. 55 | - Ben: at the very least i'll go through the repo and capture anything obviously out of date 56 | -------------------------------------------------------------------------------- /minutes/2023-01-24.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - January 24, 2023 2 | 3 | 4 | Attendance 5 | Alexeusgr 6 | Andrew Westberg 7 | Ben Hart 8 | Ignacio 9 | Jon Bauer 10 | Matthias[LOXE] 11 | Philip DiSarro 12 | Sebastian Pabon 13 | Simon Thompson 14 | Steve Lockhart 15 | The Ancient Kraken 16 | Titan-C 17 | Waalge 18 | 19 | 20 | 21 | Minutes 22 | 23 | 24 | 1. Nix 25 | - Alex: I made contact with Nix maintainers and we may be able to establish a relationship with them - I'm not personally sure what difficulties people have with nix currently as it seems quite project-specific. 26 | - Ben: Open call for nix difficulties - I recall Simon and I having a conversation about how nix can be a double-edged sword, but this may be about the difficulty of build pipelines, however nix itself has pushed some bugs/regressions and often neglects mac support. 27 | - Waalge: What is the history or context of haskell.nix? 28 | - Ben: I can link a video that describes the origin story, it's tied to difficulty when doing profiled builds with cabal2nix, which would be the non-IOG. Our (Mlabs) issues with haskell.nix is that we feel that we could speed up builds significantly with experimental nix features, particularly recursive nix - but it's not trivial work. 29 | - Simon: We can try to bring MPJ in to a future meeting to discuss problems 30 | - Ben: CHaP may eventually allow us to get away from nix altogether. 31 | - Phillip: This is a bit of a segueway into plutus starter, but when i teach new developers at Emurgo, Nix is a huge barrier. A tremendous amount of investment has gone into docker and it runs the entire rest of the mainstream software world - We should make serious efforts to provide as many containers as possible? 32 | - Ben: any experience with Arion? it's a nix wrapper around docker that may help us bridge the gap. 33 | 2. Plutus Starter 34 | - Phillip: The plutus-starter repo is really good, it's a docker container that gives you everything you need to get started - it's just got a maintenance issue around mac compatibility and plutus v2 support. 35 | - Ben: It appears to be Konstantinos L. maintaining it. 36 | - Simon: This feels like low hanging fruit, perhaps we can make some progress here and get some real results. 37 | - Ben: Phillip and I can get some documentation around this in our issues/proposals so that we test out the flow and see what success on a devexp working group initiative looks like. 38 | 3. CI/CD workflow 39 | - Ben: I spoke to Alex Appledoorn last week and it seems that there's some work going on with Lace that can have an enormous impact on developer workflows. Lace is about to open source support for working with a local private network. I can't undervalue this work to you, it's quite huge for developer workflow, it will be the first light wallet to support arbitrary networks end-to-end. This will allow E2E testing and live dApp debugging. All i'm asking for is for IOG to announce victory here and flaunt it. document it really well and tell everyone. it's also a differentiating feature for lace that could make lace the default wallet for developers. Especially if the memory footprint for all the infrastructure is 32GB or less (blockfrost requires 64gigs) 40 | - Phillip: Many developers who go through the plutus pioneer program are taught to debug using the emulator - which is not really good integration testing. Lucid now has an emulator - but working with a real private chain is a whole different and much better experience. 41 | - Simon: I'll let some of the technical leads on lace know about this too. 42 | - Ben: One key usecase is being able to run scripts with tracing enabled - this can't be done on any public testnet as it requires a config change from Mainnet.. 43 | 44 | 4. upcoming agenda (& guests) 45 | - next week: testing (Bruno/Romain from Certification) 46 | - two weeks out: devops/nix (MPJ/Angermann?) 47 | - three weeks out: Plutus Starter (Konstantinos L) 48 | -------------------------------------------------------------------------------- /minutes/2023-02-07.md: -------------------------------------------------------------------------------- 1 | Many different groups within IOG with differing levels of nix experience has resulted in a lot of inconsistency with nix builds. 2 | 3 | The goal is to get it to be usable with just cabal and no reliance on nix. 4 | 5 | Docker container for plutus depricated because maintaining it was very difficult. 6 | 7 | Make PR to Plutus-Apps with Demeter docker containers link. 8 | 9 | IOHK dev experience team has been primarily focused on internal developer experience, however, they are beginning to hire for 10 | an external developer experience team who will run through the plutus pioneer program and identify pain points to try and resolve. 11 | 12 | upcoming agenda (& guests) 13 | next week: Discuss topics for Plutus Apps. 14 | two weeks out: Talk with Plutus Apps developers 15 | -------------------------------------------------------------------------------- /minutes/2023-02-21.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience working group February 21 2 | 3 | ## Attendees 4 | Alexeus 5 | Andrew Sutherland 6 | BenHart-Mlabs 7 | Demmy 8 | harryprayiv 9 | igodlab 10 | JamesDunsieth-gimbalab 11 | jonathan777 12 | Jose Seraquive 13 | konstantinos.lambrou 14 | Las 15 | Mattchain 16 | Philip DiSarro 17 | Sebastian Pabon 18 | Simon Thompson 19 | The Ancient Kraken 20 | waalge 21 | 22 | 23 | ## Minutes 24 | 25 | 1. Proposal for restoring Plutus-Starter support & maintenance. 26 | - Ben: This proposal stems from a previous conversation (Feb 7), where Philip brought up the relative popularity and accessibility. I've written this basic proposal, so my ask is 'what is the burden of information/supporting evidence needed to move this forward?' (link to proposal PR:https://github.com/input-output-hk/Developer-Experience-working-group/pull/53/files ) 27 | - Simon: Clarifying the ask in a one-pager would be helpful. 28 | - Andrew: This might be better as a series of seperate containers? then you can write code while you wait a week for sync time. 29 | - Ben: sync time is a seperate issue, but generally i would say we need a cache that includes a fully synced testnet node in the future, because developers care much more about being able to place a transaction right now than necessarily having a perfect picture of chain history that is verified and pulled in a non-centralized fashion. Multiple containers is fine. I would say the ask is for a budget adjustment to ensure that we're maintaining a solid docker-first approach to getting a reasonable developer environment up. 30 | - JamesDunsieth: CI or manually managed? 31 | - Philip: i believe nix can be leveraged to generate containers, I don't think it really matters if it's one container or many, it's really about pointing developers to a good set of defaults for (1) compiling scripts, and (2) for running a node to submit transactions. 32 | - Waalge: Pab is a critical part of that story and while it may be possible to submit transactions, production deployment or usage with a light wallet is still an open question. 33 | - Philip: PAB is very much still an open but seperate problem that we need to examine, however right now it takes students at emurgo academy more than a week often to get the latest cardano dependencies up and running and we're really looking for a set of good defaults. At this point when it comes to PAB, there are some fundamental design decisons that causes it to remain quite bad at working with light wallets, which have exploded in popularity. Perhaps in the future IOG can look at fully embracing something like CTL or Lucid, which are quite plug and play. 34 | - Ben: To wit, they did fund CTL extensively last year. 35 | - Philip: yes, but i mean embracing it in terms of education, acknowledging these tools as part of the best practices for building on cardano. 36 | - Ben: Just to redirect, i'm still quite interested in understanding the requirement to move this forward 37 | - Simon: elaborate on the scope / implementation (automated? manual) 38 | - Ben: wouldn't that fall to someone like Konstantinos? Choosing him just because he has the last commit on the existing repo. Moreover, isn't it an engineering decision that someone at IOG would make. 39 | - Simon: Yes, but reviewing some options would be helpful. 40 | - Andrew: comprehensive starter kit is difficult because of IOG internal organization, so it's very difficult to answer the broader questions about what it would take to move this forward. 41 | - Ben: I'm sympathetic to those challenges, however for this group to have meaningful effect, it's critical to answer those questions. 42 | 43 | 44 | -------------------------------------------------------------------------------- /minutes/2023-03-07.md: -------------------------------------------------------------------------------- 1 | # Minutes For Developer Experience Working Group Meeting - Tuesday March 7, 2023 2 | 3 | 4 | ## Attendance 5 | Anita Jovic 6 | alexeusgr 7 | BeRewt 8 | BenHart-MLabs 9 | Jose Seraquive 10 | Sebastian Pabon 11 | Thiago OUROS 12 | Igodlab 13 | Santiago Carmuega 14 | waalge 15 | 16 | 17 | 18 | ## Minutes 19 | 20 | 1. Docs for Cardano-node-emulator 21 | 22 | - Alexeusgr: I am working with this new package while building a contract using helios, along the way i will try to write docs or do a tutorial. 23 | - Ben: That would be really beneficial, especially as it seems to be getting moved from another project. At MLabs we primarily use plutus-simple-model for these emulation checks, be aware that it won't give you realistic behavior of the real chain, especially around budget calculation - there are a bunch of edge cases. the emulator is only checking if the plutus script succeeds. 24 | 25 | 2. Docs for Plutus-e2e-tests 26 | - Alexeusgr: I will probably focus on cardano-node-emulator first 27 | - Ben: yeah, it seems like this is a package for testing plutus-core itself? 28 | 29 | 3. e2e testing 30 | - waalge: It would be great to discuss e2e tests more generally. 31 | - Ben: 'e2e' has always been a bit tricky with Cardano. Lace wallet is open sourcing tools to use it with any network including private ones, Currently no other wallet supports arbitrary testnets so true e2e tests need to use a public testnet unfortunately. the cardano-transaction lib also packages a fake wallet we can inject, this is used for running a headless browser and checking that your offchain code can function correctly and call the chain/indexers correctly. Otherwise we do a lot of testing with `plutip` and `plutus-simple-model`, But we know other auditors that work exclusively with the node and bash scripts, it's totally valid to do so, though you may lose some reproducibility. 32 | 33 | 4. naming the cardano-docs section for ecosystem tools. 34 | - Anita: We have a request to add mesh docs from CardanoDocs, our main question is what should this be called? 35 | - Ben: Any strong opinions beyond 'Cardano Ecosystem Tools'? (no additional suggestions) 36 | - Ben: we can revisit next week if you like, but that's a decent name if IOG wants to ensure it's distanced somewhat from ecosystem projects. 37 | 38 | 39 | -------------------------------------------------------------------------------- /minutes/2023-03-14.md: -------------------------------------------------------------------------------- 1 | # Minutes - Developer Experience Working Group - March 14, 2023 2 | 3 | 4 | ## Attendance 5 | Alexeusgr 6 | Benhart 7 | Santiago Carmuega 8 | Steve Lockhart 9 | 10 | 11 | 12 | ## Minutes 13 | 1. Proliferation of wallets 14 | - Ben: stumbling into the meeting - it looks like many of our regular attendees may have been effected by daylight savings time, i'll double check our scheduling. 15 | - Ben: a topic that came up was the proliferation of wallets, we have like 15 different wallets, Last week was sort of wallet-security week on twitter. 16 | - Steve: it seems like a lot of devs are using either Eternl or Nami exclusively, there must be a better story for testnet compatibility 17 | - Ben: Eternl is pretty tricky to support, multi address wallets are all quite tricky. 18 | - Steve: I know the developers of game-changer wallet. Not sure how they really earn any money 19 | - Santiago: There are a lot of different wallets that have very different opinions about when to balance or who builds the transaction 20 | - Ben: Balancing is interesting, currently dApp developers are dealing with this, and i'm not entirely sure that they should 21 | - Santiago: It would be great if we could find a user-friendly way to provide balancing options, without exposing the UTXO, or by making it a power-user feature 22 | 23 | 2. Sync Time & Caching 24 | - Ben: @Santiago - you may have some good input here, though I want to discuss this again when we have more people present. Today, syncing a node & indexer from scratch can take multiple days. Essentially i'd say we have two demographics who have very different needs (1) the demographic of decentralization maximalists who want cryptographic assurance that the chain is authentic, and (2) Developers who just want to place transactions as quickly as possible. 25 | - Santiago: Yes, on TxPipe we're mainly concerned with developers, so when we spin up a node, we copy in all of the syncing up to a given epoch, so we're only validating a tiny percentage of the chain in a decentralized manner. Mithril will also help with this, However i was speaking with Matthias (Benkort), and currently it appears that there isn't a lot of motivation for anyone to run the mithril infrastructure since it's not tied to stake rewards. 26 | - Ben: oh that's interesting, i had thought that Mithril would be rolled into the node directly. I was actually concerned because we hadn't seen it on the scope for the Chang Hardfork yet. But really we only see CIP 1693 there right now, though i beleive there are also a few minor plutus improvements such as Sum-of-Product generics. This makes me concerned as we may be waiting over a year for Mithril to land. 27 | -------------------------------------------------------------------------------- /minutes/2023-03-21.md: -------------------------------------------------------------------------------- 1 | # Developer Experience Working Group - March 21, 2023 2 | 3 | 4 | # Attendance 5 | Aleksei Seregin 6 | Ben Hart 7 | BeRewt 8 | Ignacio 9 | jamesdunseith 10 | Jose Serquive 11 | MattChain 12 | 13 | Philip DiSarro 14 | Randall 15 | Romain Soulat 16 | Steve Lockhart 17 | waalge 18 | 19 | 20 | # Minutes 21 | 22 | 1. Co-chairs 23 | Ben: We're currently below the optimum number of co-chairs in case someone is travelling or sick. If you have 2-5 hours of spare time in your week and would like to look at a way to give back to the Cardano community, we'd really love to have you, please let us know via DM or post in the #devexp-general channel if you'd like to join us as part of the co-chair team. 24 | 25 | 2. Daylight savings issues 26 | Ben: Last week and this week both had issues with the Discord invite because North America has changed to Daylight Savings while Europe has not. Hopefully we can catch this in advance next time. 27 | waalge: There a google-calendar invite that should be able to track UTC. 28 | Ben: I beleive that invite is run by Ignacio? 29 | Ignacio: No I don't believe so. 30 | Ben: Perhaps Anita or someone else at IOG then. 31 | Ben: I don't know if there is a solution, I feel like daylight savings causes so much misery There must be some good solutions. unfortunately Discord does not allow you to lock to a particular timezone other than your own. I will look into solutions if any exist, otherwise we'll just have to be vigilant. 32 | 33 | 3. Sync Time and Caching 34 | Ben: So i kind of want to confirm a suspicion, Cardano Sync times are notoriously long, In particular i think DBSync at one point boasted a 5 day sync time. How badly are typical developers impacted by sync times for either the node or an indexer? 35 | Marshall: the smart contract team has actually done a huge amount of work on DBSync and gotten the sync time down to 51 hours. There is also work on a lightweight chain indexer called Marconi, and outside of IOG there is a very fast indexer called kupo. 36 | Ben: We use kupo internally at Mlabs quite a lot, I didn't know about the improvements to DBSync, that's really great! But i would still say that many tools including the node will have what i will call broadly 'an inconvenient amount of time' to sync up. so i suppose I want to ask if a cache or snapshot would totally solve this issue? how much do other developers care about getting a totally accurate, verified picture of the chain vs. being able to put through a test transaction ASAP? 37 | waalge: This lines up with my own experience, however right now i typically get a snapshot of the chain and then the indexers sync up quite quickly. 38 | Ben: IOG provides snapshots? 39 | waalge: actually it's csnapshots.io 40 | Ben: That's actually huge, and goes a long way to solving the problem, pre-synced indexers would be another step in the right direction, but this is great. 41 | Marshall: who builds that? 42 | Ben: it seems to be an SPO - 24/7 StakePool is the name 43 | 44 | 45 | 4. Effectiveness of the Group 46 | Ben: Early on a recommended metric to measure the group's efficacy was 'How many proposals are written?' - personally i would argue this is a bad metric, because one of my personal metrics is about real-world impact. But there are alternate priorities this group can take - for example as a mutual support group. For me - i feel that projects that are identified as issues and then become proposals with sponsors who actually end up shipping something or making some new capability or way for developers to save time should measure the effectiveness of the group - however by that metric, we're not doing great. What are other people's feelings here. 47 | 48 | Ignacio: I agree that real-world impact should be the measure of efficacy. IOG is in an odd situation here as we have limited resources and have provided mainly organizational assistance. this group has been the most consistent in terms of organization. 49 | Steve: I wish this group was able to set some common priorities, it would be nice if IOG was represented more as one of us. 50 | waalge: it's good to have a place to speak directly with IOG / have solidarity. At the same time we as individual projects have extremely limited resources in relation to IOG, so it seems like one of the best approaches is to help IOG guide the deployment of it's resources toward the best targets. 51 | Randall: the ultimate metric would be to take some kind of measurement of the time necessary to take a competent developer in general, and train them to be a competent Cardano Developer. Any time we can shrink that time, we have succeeded. 52 | Ben: We'll have to wrap up there. Thanks for your time everyone. 53 | -------------------------------------------------------------------------------- /minutes/2023-03-28.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - March 28, 2023 2 | 3 | 4 | ## Attendance 5 | Aleksei 6 | BenHart 7 | FluxCap 8 | Ignacio 9 | JamesDunseith 10 | Jose Seraquive 11 | Las 12 | Philip DiSarro 13 | Sebastian Pabon 14 | waalge 15 | Marshall Swatt 16 | 17 | # Minutes 18 | 19 | 20 | Topic: Open call for new issues to prioritize 21 | Ben: I wanted to start by refocusing now that daylight savings is over, we've spent several weeks investigating rabbit holes. so now might be a good time to talk about what's changed in the ecosystem, and what the biggest problems are today. 22 | Philip: For folks who don't know me, In addition to work I do with Ikigai, I also work as an instructor at Emurgo academy. I was skeptical when I first joined this group, but i have to say there have been some real improvements. From IOG working to improve docker support, to using some key new frameworks in their public projects like the sidechain project. Things are getting a lot easier for students and the new plutus pioneer program is doing a lot of things right. 23 | Ben: That's really great news, What are the outstanding problems? 24 | Philip: Now that the basics are covered, I would say design patterns are the next major hurdle, The Plutonomicon is really the only resource out there. 25 | Ben: Yeah, that makes sense, the Plutonomicon itself was always a stop-gap that was assembled ina scramble while trying to ship, as a way of describing ideas from our research. though a lot of that work was really about trying to overcome the lack of reference inputs before the vasil hardfork. 26 | Philip: I'm actually saying there should be a more polished/central official resource for ways of building these kinds of nontrivial onchain architectures. 27 | 28 | Topic: Emulators 29 | Marshall: Is there a need out there for a standalone Emulator Binary? 30 | Philip: Not desperately, we have a number of emulators across the ecosystem. 31 | Ben: I'd say the only real problem with existing emulators lately is that there isn't a binary that has the same API as the cardano node itself, nothing is language-agnostic. everything is packed away as part of one library or the other, a lot of them requiring haskell. 32 | 33 | Topic: Other Business, Updates, and Next Week's Agenda 34 | Ben: Co-chairs - we still need them. If you're looking for a way to give back to the cardano community and have something to the tune of 2-5 hours a week available, we'd really appreciate if you'd get involved, let us know in these meetings, on the #devexp-general discord channel, or via DM if you're interested. 35 | aleksei: There have been a lot of updates from Plank labs and the standalone example 36 | Ignacio: this could be next week's meeting if that's ok. 37 | Ben: it is. 38 | 39 | Ben: Last week we spoke about centralized caches as a way to help developers avoid long sync times - @waalge pointed out cardanosnapshots.io - which is a great resource! However my team quickly noticed that they don't snapshot the new preprod and preview testnets, only the legacy testnet. 40 | Philip: db-sync's repository also links to caches for db-sync and needs to start including the new testnets as well 41 | Marshall: I'll ask the dbsync team about that. 42 | Ben: Thanks for your time everyone, see you next week! 43 | -------------------------------------------------------------------------------- /minutes/2023-04-04.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - April 4th, 2023 2 | 3 | Attendance 4 | Anusheel 5 | Alex 6 | Ander Sutherland 7 | BenHart 8 | Computational 9 | Ignacio 10 | James Dunseith 11 | Jose Seraquive 12 | Joseph Fajen 13 | Konstantinos Lombrou 14 | MattChain 15 | Marshall Swatt 16 | Manu Gunther 17 | Simon Thompson 18 | Romain Soulat 19 | Santiago Carmuega 20 | Sebastient Pereira 21 | 22 | Minutes 23 | 24 | Ignacio: Today we have Anusheel and Manu from Plank Labs presenting and end-to-end application they have built with PAB. Lets give a warm welcome. 25 | Manu: For this application, we've worked to build transactions in Haskell, the same way we build the smart contract itself. We yield the unbalanced Tx back to the Frontend for balancing to work with the various light wallets. For indexers, we initially used `chain-index`, but later we switched to blockfrost, however other indexers can easily be used here. In the last few months there have been a lot of advancements in new ways to build cardano transactions, but this is something we've been progressively working on for the past year or more. We can do a bit of a code tour - but maybe a Q&A format is best 26 | 27 | Ben: Could you paste the link please? https://cardano-e2e-example.readthedocs.io/en/latest/ 28 | 29 | Ben: How are you doing Balancing and resource estimation? 30 | 31 | Manu: Resource estimation is a seperate service we abstracted from `cardano-wallet` and created a seperate open source service. We balance on the frontend. 32 | 33 | Marshall: How does this compare with the PAB that the plutus team has built? 34 | 35 | Manu: it's the same PAB, the only modifications have been opensourced and PR's have been sent to the plutus-apps repo. We have however used it piecemeal, to facilitate transactions with light wallets, which have a different set of demands. We did produce a client library for calling it from the frontend 36 | 37 | Matt: How does it handle partial signatures? 38 | 39 | Manu: PAB cannot produce signatures from a light wallet user, 40 | 41 | Ben: How do you reconcile issues with JSON formats not reflecting frontend language expectations? (BigInts) 42 | 43 | Manu: It hasn't really come up for us. 44 | 45 | Santiago: How does this compare to Atlas and other PAB's? 46 | 47 | Manu: We also worked on Atlas with GeniusYield. The main issue with PAB is that it was monolithic and there was not clear seperation around which components should be used. Atlas is more modular. With atlas you need to create your own webservice, you get that for free with PAB. 48 | 49 | Manu: The main advantage here is that you get code sharing between Plutus contract and offchain tx building. We also provide comprehensive testing guides using the quickcheck approach. 50 | 51 | 52 | Ben: Thanks very much to plank labs for putting this together & presenting. 53 | -------------------------------------------------------------------------------- /minutes/2023-04-11.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - April 11, 2022 2 | 3 | 4 | Attendance: 5 | AndrewWestberg 6 | Anita Jovic (IOG) 7 | Ben Hart - MLabs 8 | Ignacio (IOG) 9 | IronFortress (George Flerovsky) - MLabs 10 | MattChain (Marshall Swatt) 11 | Nicolas Biri (IOG) 12 | Santiago Carmuega (Txpipe) 13 | Sebastian Pabon 14 | Steve Lockhart 15 | 16 | 17 | Minutes: 18 | Ben: Today we don't have a well developed agenda, so it will turn into a broader discussion of issues that you're encountering as developers. 19 | 20 | George: As someone new to the group - it would be great if you could give a high level review about the goals of the group and issues covered. 21 | 22 | Ben: So we have a repository which covers minutes, a charter, issues (problem statements), and Pull Request Proposals - These are proposed solutions that address the issues, which can then be taken on by a sponsor and hopefully get funding. An example I think that really followed this process was the concept of the 'hellbound' testnet - which essentially was a high-traffic testnet so that protocol developers could see how their systems behave in adverse conditions. Some other examples of issues we've examined are the burden of Nix workflows and lack of Docker support, missing documentation, Caching, the Indexer ecosystem, Emulators and Testing. 23 | 24 | George: It might be interesting then to discuss nix-caching for the ecosystem toolchain beyond what IOG provides. 25 | Santiago: We don't really use nix workflows, but I believe that for developers who do use nix, that it would be helpful. 26 | George: Then it's really a matter of funding at this point. 27 | 28 | Marshall: I have a couple of items that i wanted to ask about if I can? 29 | Ben: by all means. 30 | Marshall: we're looking at forking the node so that we can export ledger calculations for chain indexers 31 | Ben: What would be the benefit? what's the usecase? 32 | Marshall: it would be much more efficient for indexers to get staking snapshots and similar delegation information - it might let kupo get down to something like 8GB RAM. 33 | Ben: Anything we can do to reduce the RAM footprint is a great idea. to my knowledge blockfrost is the only indexer that offers the stake info - it would be great to have this available elsewhere while keeping it lightweight. To that end - there was also a change introduced in the Vasil hardfork that prevents someone trying to set up a 'simple' private network from just creating a central block producing node - instead you now need to walk through the process of registering a stakepool and getting delegation, it certainly adds to the overhead and changes the needs from running a single node to running a cluster. 34 | Marshall: I'll talk with the plutus and node team about that. 35 | 36 | 37 | Marshall: I'm also quite interested in moving forward around an emulator that maintains an ongoing ledger without all the overhead from the node. (NB: as discussed previously, this would be a language-agnostic stand-alone binary). 38 | George: You may be able to borrow quite a bit from Hydra - as it basically just maintains an in-memory UTXO set without the Ouroboros parts - it's quite lightweight. 39 | 40 | 41 | Ben: we've run out of time today, Thanks so much to everyone for coming. 42 | -------------------------------------------------------------------------------- /minutes/2023-04-18.md: -------------------------------------------------------------------------------- 1 | # Developer Experience Working Group - Minutes for April 18 2023 2 | 3 | ## Attendance 4 | Anita Jovic 5 | Ben Hart 6 | IronFortress (IronFortress) 7 | Marshall Swatt (Mattchain) 8 | Santiago Carmuega 9 | Sebastian Pabon 10 | Steve Lockhart 11 | lley154 12 | 13 | 14 | ## Minutes 15 | ### Bringing more developers into the group 16 | 17 | 18 | George: it seems like we have a turnout issue, as well as a number of participants are non-developers, yet it should be the working group's priority to involve them, it's my understanding that we have a number of product owners, and that may be very useful to developers in the ecosystem. The question is how do we get more developers involved? it's understood that funding can be quite limited for actually solving these problems. However the cataloging and prioritizing of issues can be valuable for anyone looking to build or improve these situations. 19 | 20 | Ben: we also spoke a bit about possibly making recordings of these discussions public like a podcast. 21 | 22 | Jon Bauer: That could be really handy as well - it can help address some of the problems that come up from daylight savings 23 | 24 | George: We could also bring in open source community maintainers as well. 25 | Ben: Is there any objection to taking this working group in this direction? 26 | 27 | Note: only positive reactions provided 28 | 29 | George: We could potentially solicit a lot of these guests from the IOG community discord - and use it as a means of attracting developers. 30 | 31 | Anita: It could be good to move in this direction (toward office hours format) - perhaps with a balance toward initiatives as well. 32 | 33 | Marshall: I know we were looking at doing office hours for the smart contract team. 34 | 35 | lley154: I'm on the Helios team and would be happy to get involved with this working group. at the very least it would allow for loose alignment on how we onboard developers to these alternative languages. 36 | 37 | George: Has anyone else seen Rosetta Code? it would be interesting to see the same problems solved across multiple languages. 38 | 39 | 40 | 41 | ### Next week agenda items 42 | 43 | Ben: 44 | - Production deployment 45 | - Adjusting the Working group format toward a public facing recording 46 | -------------------------------------------------------------------------------- /minutes/2023-05-23.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - May 23, 2023 2 | 3 | ## Minutes 4 | - Additional co-chair 5 | - Neil Rutledge will be assisting George Flerovsky as co-chair 6 | - Neil is a delivery manager at MLabs, but he focuses more on frontend/offchain and has been involved in multiple product launches on Cardano (in varying capacities) 7 | - Future goals of Developer Experience Working Group 8 | - Bring in more developers from other communities 9 | - Identify common issues and create problem statements 10 | - Acquire funding for resolving issues through Catalyst proposals, etc. 11 | - Scheduling meetings 12 | - It would be helpful to have a calendar invite so people don't miss meetings 13 | - George will look into creating an invite that people can import into their calendars 14 | - Chain indexer pain points 15 | - There are several chain indexers and they all have varying degrees of limitations 16 | - Neil has experienced slow Kupo queries and timeouts (also reports of needing to spin up hundreds of instances to meet production loads) but needs to investigate further 17 | - Andrew Westberg is building an indexer for [NEWM](https://github.com/projectNEWM/newm-server) that has a gRPC API, can watch smart contracts (event driven), and has client code generation 18 | - Synching types between languages 19 | - There is currently difficulty keeping types aligned between Haskell/PureScript/TypeScript, etc. 20 | - [Lambda Buffers](https://github.com/mlabs-haskell/lambda-buffers) is working on a solution 21 | - [CIP-0057](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0057) is another potential solution 22 | - The ability to generate type definitions (blueprints) could be added to Plutarch and PlutusTx 23 | - Other issues warranting further discussion 24 | - Frontend integration is generally more challenging than it should be 25 | - It's difficult to assess how DApps will scale/behave on mainnet (a testnet more closely matching mainnet would be helpful) 26 | 27 | ## Actions 28 | - George - Post calendar invite in Discord for future meetings 29 | - Neil - Get more details on potential kupo issues and other integration issues for further discussion -------------------------------------------------------------------------------- /minutes/2023-05-30.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - May 30, 2023 2 | 3 | ## Attendance 4 | - Anita Jovic 5 | - Demmy 6 | - GeorgeFlerovsky 7 | - Ignacio 8 | - NeilRutledge 9 | - waalge 10 | - Sebastian Pabon 11 | - MattChain 12 | 13 | ## Minutes 14 | 15 | **Membership** 16 | - Anita: Anyone can now join and invite new members without pre-approval 17 | - There will be an announcement about sharing invites 18 | - New members are encouraged to introduce themselves 19 | - Process to determine speakers needs to be determined 20 | - Discussion needed on the meaning of membership and how to add value 21 | - George: Knowing members' backgrounds could be helpful, information could be in usernames/descriptions 22 | - Anita: Onboarding documents and templates will be shared 23 | - George: New attendees could become members by contributing in chat 24 | 25 | **Kupo performance issues** 26 | - Neil: Kupo performance issue mentioned last week turned out to be misconfiguration (`--defer-db-indexes` needed to be disabled) 27 | - A Kupo issue about automatically creating indexes once fully synced was added 28 | 29 | **Type blueprints (CIP-57)** 30 | - MattChain: Reached out to Michael Peyton Jones about this and will get his opinion on CIP-57 support in PlutusTx 31 | 32 | **PlutusTx and Plutus team focus** 33 | - Neil: Is PlutusTx still being used now that alternatives are available like Aiken and Plutarch? 34 | - George: It is used by Hydra and other projects 35 | - MattChain: IOG wants to enable core Haskell capabilities (continuing to support PlutusTx) as well as community-built alternatives 36 | - waalge: Difficulty with initial PlutusTx usage, now using Aiken + Lucid 37 | - George: Suggested waalge look at Atlas (PAB alternative in Haskell) 38 | - Will Plutus Core team reconsider architecture now that everyone is moving to light wallets? 39 | - MattChain: Plutus team's focus is currently on emulator and modular chain indexer (Marconi) 40 | - Plutus-apps to go into maintenance mode 41 | - Plutus team will focus where there is clear community demand 42 | - George: IOG's modular components should be integratable into other platforms 43 | - MattChain: Marconi could be used in any Haskell project 44 | 45 | **Issues for next week's agenda** 46 | - Ignacio: opinions on using 3rd parties for blockchain data 47 | - Mithril coming next year 48 | - George: wallets and DApps connecting to different services can cause sync issues 49 | - Anita: someone from IOG would like to join and present 50 | 51 | ## Actions 52 | - MattChain - Get MPJ's opinion on CIP-57 53 | - George - Invite Vladimir Kalnitsky to next week's meeting 54 | -------------------------------------------------------------------------------- /minutes/2023-06-06.md: -------------------------------------------------------------------------------- 1 | # Minutes for Developer Experience Working Group - June 06, 2023 2 | 3 | ## Minutes 4 | - Chair: Neil Rutledge, Ignacio [minute-taker] 5 | 6 | - Preferably to self-host services (if the resources for experienced DevOps exists) than relying on third party services: eg. Blockfrost, Maestro 7 | - Members of the WG have seen projects using a diversity of tools like Lucid, Kupo and CTL 8 | 9 | - More specifically Kupo is very good out of the box, because it allows to selectively deal w/ specific UTXOs. However, some limitations are: 10 | - it needs to separately look up scripts and data, which results in additional requests 11 | - Handling separate caching is often needed, some projects opt to build their own indexer or add extra caching layers to Kupo 12 | - Some project w/ heavy load needs is using dynamic scripts w/ different parameterizations, in comination to an additional indexer on top of Kupo 13 | 14 | - Marconi is IOG's chain indexer library 15 | - aims to monitor bridges for side-chains 16 | - the design considers to offer precise customization -> efficient and low-cost 17 | - will keep the WG updated 18 | 19 | - PR for Plutus elliptic functions pairing has been merged, but didn't make it to CHAPS Cardano Haskell repo yet 20 | - nix-haskell, has been somewhat of a blocker for finding the right packages 21 | - more specifically expecting this to be improved with a new version of Plutus 22 | 23 | -------------------------------------------------------------------------------- /minutes/2023-06-13.md: -------------------------------------------------------------------------------- 1 | # 2023-06-13 devxp 2 | 3 | Attendees: 4 | - @nrutledge 5 | - @Igodlab 6 | - @waalge 7 | - @mattchain? 8 | 9 | ## Scribe role 10 | 11 | General concensus : we should have one. 12 | 13 | ## Action 14 | 15 | 1. Get PRs merged 16 | @nrutledge will ping people to get prs merged 17 | 18 | 2. We should go through prior meeting notes and see what can get converted to issues 19 | @nrutledge : will aim to get issues tracked 20 | 21 | 3. From there we can create proposals 22 | 23 | ## Plutus flakes 24 | 25 | 1. @waalge resolved his issues from previous. 26 | 27 | @nrutledge : try liqwid nix maybe 28 | 29 | ## Building bridges 30 | 31 | @waalge what was this? 32 | 33 | @Igodlab will find out what is happening here 34 | -------------------------------------------------------------------------------- /proposal-template.md: -------------------------------------------------------------------------------- 1 | # Proposal Title 2 | Developer Experience Working Group Proposal #X 3 | 4 | v0.1 5 | 6 | ## Preamble 7 | 8 | Provide a motivating discription so that the problem can be understood. 9 | 10 | 11 | ## Developer Experience Concerns 12 | How does the issue impact working developers and learners in the plutus space building on Cardano Layer 1? 13 | 14 | ## Proposed solution 15 | what changes could be made to IOG's offerings, cardano development and support practice, or the broader ecosystem to resolve this? 16 | 17 | ## Additional Reading 18 | motivating github issues, articles, or other resources & documents 19 | 20 | 21 | -------------------------------------------------------------------------------- /wip/well-architected-framework/README.md: -------------------------------------------------------------------------------- 1 | # Well-Architected Framework 2 | 3 | ## Rationale 4 | 5 | Cloud-development platforms usually provide a "well-architected framework" that describes their view of how to approach the development of complex systems on top of their platforms. 6 | 7 | Here are some examples: 8 | 9 | AWS: https://aws.amazon.com/architecture/well-architected 10 | Azure: https://learn.microsoft.com/en-us/azure/architecture/framework/ 11 | 12 | In essence, each framework provides a set of best-practices on how to approach different development disciplines, such as: security, reliability, performance-optimization, monitoring, tracing, etc. 13 | 14 | Having a "Cardano Well-Architected Framework" in a similar fashion to the mentioned above would serve as useful guidelines for developer teams entering the ecosystem. 15 | 16 | ## Roadmap / Status 17 | 18 | - [ ] Define scope for v1 19 | - [ ] Identify KOLs for each topic 20 | - [ ] Gather content from KOLs 21 | - [ ] Prepare draft document 22 | - [ ] Gather feedback 23 | - [ ] Publish v1 24 | 25 | > KOL: A key opinion leader (KOL) is an individual who is widely recognized as an authority or expert in a specific field or industry. 26 | 27 | ## How to contribute 28 | - By submitting a PR with changes to the scope (table of contents) 29 | - By creating a new .md file that includes relevant information on any of the specific topics (it can be references to outside material or original content) 30 | - By proposing candidate KOLs that would pontentially be able to fullfil the content for any of the topics. 31 | 32 | ## Scope 33 | 34 | The following is a _live_ list of topics that the Well-Architected framework for Cardano should include. It's organized by broad disciplines that are involved in the process of building a dApp. 35 | 36 | 1. Reliability 37 | 2. Security 38 | 3. Cost Optimization 39 | 4. Performance 40 | 5. Decentralisation 41 | 6. Scalability 42 | 7. UX/UI 43 | 44 | Each discipline describes relevant _principles_ and _best practices_. 45 | 46 | > **Principle**: a fundamental rule or guideline that should be followed when designing and building software applications. Principles are typically broad, general statements that provide guidance and direction for software development. 47 | 48 | > **Best Practice**: a specific approach or technique that has been shown to be effective in solving a particular problem or achieving a specific goal in software development. Best practices are typically based on the experiences and expertise of experts in the field, and they provide guidance on how to design and implement software in a way that is maintainable, scalable, and extensible. 49 | 50 | > **Reference Implementations**: a set of examples to illustrate Principles and Best Practices. Reference Implementations may include live projects, specific architectures, or topologies for decentralised applications. 51 | 52 | ### Reliability 53 | Reliability refers to the ability of a system to consistently provide access to data and services, regardless of hardware / software failures and excessive load. Reliability implies responsiveness, consistency and correctness of the data and processes of the system. The end-goal is to provide users with access to the resources they need, whenever they need them, without interruption. 54 | 55 | Development teams should be aware of how to develop Cardano applications that avoid common SPOs (single point of failure) and implement fallback mechanisms by taking into account principles such as automation and observability early on, during the design phase of their projects. 56 | 57 | #### Principles 58 | - Design for business requirements 59 | - Design for failure 60 | - Observability 61 | - Automation 62 | - Self-healing 63 | 64 | #### Best Practices 65 | - Permanent Failure Handling 66 | - Transient Failure Handling 67 | - Congestion Handling 68 | - Rollback Handling 69 | - Tx Retry Policies 70 | - Traffic Load Balancing 71 | 72 | #### Reference Implementations 73 | 2-3 sentence introduction highlighting some key decisions dev teams will need to make - Santiago 74 | 75 | 76 | ### Security 77 | 78 | #### Principles 79 | - Identity Management 80 | - Infrastructure Security 81 | - Application Security 82 | - Contract Security 83 | - Contract Auditing 84 | - Property-based Testing 85 | 86 | #### Best Practices 87 | - Client-side Wallet Integration 88 | - Server-side Key Management 89 | - Node Network Topology 90 | - Plutus Testing Pipeline 91 | 92 | #### Reference Implementations 93 | 2-3 sentence introduction highlighting some key decisions dev teams will need to make - Santiago 94 | 95 | ### Cost Optimization 96 | 97 | #### Principles 98 | - Cost Estimation 99 | - Cost Models 100 | - Cost Monitoring 101 | - Capacity Planning 102 | 103 | #### Best Practices 104 | - Cardano Node Capacity Planning 105 | - DB-Sync Capacity Planning 106 | - Dynamic Scaling 107 | 108 | #### Reference Implementations 109 | 110 | ### Performance 111 | To determine the responsiveness, speed, scalability, and stability characteristics of the application under stress tests and aligning to production requirements. End-to-end performance throughput of any application should support anticipated peak production load, including network load. Tests should detect concurrency issues and functionality errors when under load. 112 | 113 | These tests should be performed without overloading the Cardano blockchain. Developers should in their best knowledge, determine how many users the application can handle before performance is compromised. Developers should determine failure plans before causing failures and errors in addition to congestion of the network. 114 | 115 | 116 | #### Principles 117 | - Load Testing 118 | - Stress Testing 119 | - Process Profiling 120 | - Plutus Cost Model 121 | 122 | #### Best Practices 123 | - Mempool Optimization 124 | - Tx Chaining 125 | - Plutus Script Optimization 126 | 127 | #### Reference Implementations 128 | 129 | 130 | ### Decentralisation 131 | 2-3 sentence introduction highlighting some key decisions dev teams will need to make - Michele 132 | 133 | #### Principles 134 | - Robustness 135 | - Censorship Resistance 136 | - Open Source 137 | - Shared ownership 138 | - Independence 139 | 140 | #### Best Practices 141 | - Eject buttons 142 | - Headless Dapps 143 | 144 | #### Reference Implementations 145 | 146 | 147 | ### Scalability 148 | Project architectures should be designed with scaling in mind, even when starting small. Development teams must be aware of the design challenges inherent in scaling applications on Cardano. This framework provides an overview of potential tradeoffs between Scalability and other disciplines, so that development teams can build for present and future use. 149 | 150 | #### Principles 151 | #### Best Practices 152 | #### Reference Implementations 153 | 154 | ### User Experience UX/UI 155 | User Experience covers the component architecture and UI Elements of a dApp, that ensure the smoothest experience possible. Whether it’s reading data of the blockchain, or submitting new data. The experience shouldn’t be any different from interacting with a regular WebApp. 156 | 157 | #### Principles 158 | #### Best Practices 159 | #### Reference Implementations 160 | --------------------------------------------------------------------------------