#dusk $DUSK @Dusk suýt chút nữa đã biến toàn bộ danh mục của tôi thành tro bụi
Tôi đang làm một nhiệm vụ giao dịch Dusk và vô tình mở một vị thế lớn hơn nhiều so với dự định 😭
May mắn là tôi nhận ra kịp thời và đóng nó trước khi nó có thể thanh lý tôi. Bachat Hogai...
Tôi cứ thắc mắc khi nào một thay đổi được đề xuất cho @Dusk thực sự trở thành một phần của giao thức.
Có vẻ như viết một DIP thuyết phục chỉ mới là bước bắt đầu.
Một Đề xuất Cải tiến Dusk sẽ đi qua các giai đoạn Ý tưởng, Bản nháp và Phản hồi trước khi tới Giai đoạn Staging. Nếu đề xuất liên quan đến việc triển khai kỹ thuật, giai đoạn staging đó sẽ đưa nó lên mạng thử nghiệm Nocturne để thực hiện vòng kiểm thử và phản hồi cuối cùng.
Chỉ sau khi nó nhận được sự đồng thuận và các đầu ra (deliverables) của đề xuất được đưa vào môi trường production thì đề xuất mới trở thành Active.
điểm tách biệt này rất quan trọng.
Một tài liệu đã được gộp có thể giữ lại đặc tả và lý do đằng sau một thay đổi, nhưng điều đó không tự động có nghĩa là mọi node đã làm theo quy tắc đó trên mainnet. Tính “trưởng thành” của đề xuất và việc kích hoạt trong production là hai trạng thái khác nhau.
Quy trình cũng có một nhánh không hoạt động (inactivity).
Một đề xuất không còn được phát triển có thể chuyển sang Stagnant. Nếu nó vẫn ở đó hơn sáu tháng, có thể bị đánh dấu là Dead. Vì vậy, kho lưu trữ sẽ giữ lại những ý tưởng thất bại trong quá trình tiến triển thay vì khiến mọi đề xuất cũ cứ trông như đang chờ mãi.
Tôi thích lịch sử nó tạo ra: động lực, đặc tả, khả năng tương thích, các bài test, cân nhắc bảo mật và các tài liệu tham chiếu triển khai đều gắn với quyết định.
Nhưng một hồ sơ có cấu trúc không loại bỏ việc phải phán xét. Các biên tập viên và người đóng góp vẫn phải quyết định khi nào phản hồi là đủ, liệu đã có sự đồng thuận hay chưa và liệu việc triển khai có thực sự đáp ứng đúng đề xuất được viết hay không.
Vòng đời DIP giúp việc kiểm toán thay đổi giao thức dễ hơn, hay nó lại đặt những quyết định quản trị khó nhất vào các giai đoạn chuyển tiếp mà tài liệu đơn thuần không thể tự giải quyết??
#dusk @Dusk
Tôi đang làm một nhiệm vụ giao dịch Dusk và vô tình mở một vị thế lớn hơn nhiều so với dự định 😭
May mắn là tôi nhận ra kịp thời và đóng nó trước khi nó có thể thanh lý tôi. Bachat Hogai...
Tôi cứ thắc mắc khi nào một thay đổi được đề xuất cho @Dusk thực sự trở thành một phần của giao thức.
Có vẻ như viết một DIP thuyết phục chỉ mới là bước bắt đầu.
Một Đề xuất Cải tiến Dusk sẽ đi qua các giai đoạn Ý tưởng, Bản nháp và Phản hồi trước khi tới Giai đoạn Staging. Nếu đề xuất liên quan đến việc triển khai kỹ thuật, giai đoạn staging đó sẽ đưa nó lên mạng thử nghiệm Nocturne để thực hiện vòng kiểm thử và phản hồi cuối cùng.
Chỉ sau khi nó nhận được sự đồng thuận và các đầu ra (deliverables) của đề xuất được đưa vào môi trường production thì đề xuất mới trở thành Active.
điểm tách biệt này rất quan trọng.
Một tài liệu đã được gộp có thể giữ lại đặc tả và lý do đằng sau một thay đổi, nhưng điều đó không tự động có nghĩa là mọi node đã làm theo quy tắc đó trên mainnet. Tính “trưởng thành” của đề xuất và việc kích hoạt trong production là hai trạng thái khác nhau.
Quy trình cũng có một nhánh không hoạt động (inactivity).
Một đề xuất không còn được phát triển có thể chuyển sang Stagnant. Nếu nó vẫn ở đó hơn sáu tháng, có thể bị đánh dấu là Dead. Vì vậy, kho lưu trữ sẽ giữ lại những ý tưởng thất bại trong quá trình tiến triển thay vì khiến mọi đề xuất cũ cứ trông như đang chờ mãi.
Tôi thích lịch sử nó tạo ra: động lực, đặc tả, khả năng tương thích, các bài test, cân nhắc bảo mật và các tài liệu tham chiếu triển khai đều gắn với quyết định.
Nhưng một hồ sơ có cấu trúc không loại bỏ việc phải phán xét. Các biên tập viên và người đóng góp vẫn phải quyết định khi nào phản hồi là đủ, liệu đã có sự đồng thuận hay chưa và liệu việc triển khai có thực sự đáp ứng đúng đề xuất được viết hay không.
Vòng đời DIP giúp việc kiểm toán thay đổi giao thức dễ hơn, hay nó lại đặt những quyết định quản trị khó nhất vào các giai đoạn chuyển tiếp mà tài liệu đơn thuần không thể tự giải quyết??
#dusk @Dusk