HIP-1: Hedera Improvement Proposal Process

[kenthejr]

This discussion is designated as the discussions-to target of hip-1. Use this thread to further develop the HIP.

[kenthejr]

Should we add a field called implementer that suggests that someone has taken up the mantel of building a reference implementation?

I think it could reduce the risk of multiple parties "claiming" a HIP for implementation and duplicating effort...at the very least, if people want to duplicate effort (or compete) they are doing so knowing that someone else is publicly tackling it.

[kenthejr]

I think I'm coming to the same conclusion. Maybe instead of pointing to a person who is the "implementer" the right way might be to point to the implementation repo. That way we can see if it's active or not and remove it if it goes stale and let another repo pick it up.

[kenthejr]

Do you think we should add a property to the top matter for implementation-repo and just make that a link?

[ec2ainun]

i'm not quite sure, what do you mean by just make that a link

lets take eips for example, there is core code on final proposal
but we can't easily validate and testing out the implementation,
it's not elegant if we include readme like on how to setup, how to run, required lib, etc (complex implementation or new people perspective)

lets me elaborate on my previous answer, yes we need a link implementation repo on repository section, but after it's reach final stage, it's still open discussion if we need to remove/review the repositories section

on final HIP we still need to include core code as partner in explaining things, and reference on actual repository to easily validate and testing out actual implementation,
perhaps after reach final HIP, we need to move and centralize on single repo that managed by hedera github organization in case reference repository is deleted/moved/renamed

disclaimer: this is just an opinion, i'm quite new in DLT world 😄

[kenthejr]

The goal here is to signal to the world that someone has taken up the mantel of building the reference architecture. That way we don't end up with redundant efforts. I'm just wondering if we should signal that as a top-matter property of the HIP or maybe just in the Reference Implementation section (which kind of makes sense). I think it makes sense for that signal to be a link to another GitHub repo where people can see the reference implementation working.

[ec2ainun]

i see, yeah i also support reference section, because the point of proposal is the whole content, implementation is just a part of it 👍

[eclectocrat]

I suppose it can go into the discussion or rationale, but in cases where a HIP is motivated by an existing example, perhaps in another ledger tech, it would be good to point to a functioning, already used implementation of the content of the HIP. This helps with determining trade-offs and feasibility, as another team may have encountered hiccups that can be useful in initial HIP analysis.

[kenthejr]

I agree with that. I'm thinking about the Hedera-version of the reference implementation. For example, if we pointed to Compound as an example in the Rationale, someone still needs to write the code that works w/ Hedera. That code is the reference implementation. I'm a bit sensitive to multiple people working on it at the same time. Looking for a way to indicate that someone is already working on it.

I guess the negative side is that someone could slow down development by "claiming" a HIP and making people think someone is already working on it. Should there be a requirement to reference a Github repo?

[rahul-kothari]

Based on the discussion around HIPs yesterday, I would like to see what we all think about a few changes:

1. Update the readme of this repo to clearly say that HIPs must be small, granular and not a broad idea
2. Both the readme and HIP-1 be updated to show that the new process should be
   i. Float an idea in the discussions section of this repo
   ii. If the idea gets some traction, develop a tech reference (and this is why HIPs should be something small, granular)
   iii. Only then can authors create a HIP.
3. When a HIP is committed into the repo, the current commit messages just say "Add HIP-N". Instead commit messages should also include the title of the HIP to make searchability easier.
4. (Controversial) Most HIPs that are in draft are so because almost none of them have a technical reference. As such, I think we should review all the current HIPs are withdraw/defer the ones which aren't too granular or where the creation of a technical reference is too hard. For example: HIP 12 on ZKPs by me

I think (4) is crucial because most of the HIPs in the repo aren't HIPs. They are just ideas. As such, I am happy to withdraw/defer HIP-12.

This doesn't mean that broad business ideas are discouraged. If any idea (in the discussions tab) gets a lot of traction, then I am sure that the Hedera Dev team could be persuaded to help us build on it from a technical perspective.

Thoughts?

[kenthejr]

I agree with all of your suggestions. Updating the README.

I'd suggest that a reference implementation be optional before a HIP gets merged. Even some small HIPs can be difficult to demonstrate. Having a complete reference implementation on submission does make the HIP stronger and more likely to get to Final status sooner, but I don't want it to be a blocker if the specification has good roots.

[kenthejr]

Regarding 3, there is a limited number of characters in a commit. It's a bit hard to fit a title (especially longer titles) along w/ a meaningful message. I'm wondering if maybe to improve searchability, maybe just add a table with a summary of HIPs in the README?

[kenthejr]

Submitted a PR with an approach. Let me know if this addresses your feedback: #76

[kenthejr]

Merged and closed.

[kenthejr]

A recommendation was made to shift the front-matter from a strictly horizontal table to a vertical property list. For example:

Current

---
hip: 1
title: Hedera Improvement Proposal Process
author: Ken Anderson (@kenthejr)
type: Process
status: Draft
created: 2021-02-11
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/54
---

Proposed

```
hip: 1
title: Hedera Improvement Proposal Process
author: Ken Anderson (@kenthejr)
type: Process
status: Draft
created: 2021-02-11
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/54
```

[mehcode]

I would recommend a bulleted approach, mainly so we can make use of formatted links (which aren't allowed in the current front matter style).

• HIP: 1
• Title: Hedera Improvement Proposal Process
• Author: Ken Anderson
• Type: Process
• Status: Draft
• Start Date: 2021-02-11
• Discussion: #54

[kenthejr]

I prefer this format too.

[coltsfanatic07]

Vertical definitely will look better, plus the benefit of formatted links, I'm all for it.

[kenthejr]

add PR to address this: #87

[kenthejr]

Hedera Council Technical Committee has ratified this HIP

Once the FINAL CALL FOR COMMENT period has expired and no additional concerns have been raised, this HIP will move to its final state based on its type.

[kenthejr]

FINAL CALL FOR COMMENT

This HIP is scheduled for progression to Final status if no other contributions are made by the community. If no issues are raised or pull requests made within the next 7 days, this HIP will be updated to Active status.

[rodrigonunes100]

It would be nice if hedera had an official .NET smart contract sdk.

[bugbytesinc]

The .NET SDK already supports smart contracts.

[rodrigonunes100]

Where to find? I can't find it anywhere.

[bmgentile]

Would like to suggest adding "User Stories" to the HIP-1 template so that when new functionalities are proposed, it's clear how these functionalities would be used in certain applications.