Review network types distribution
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- go
- Área
- backend, data, networking
Línea de trabajo
Comienza rastreando cómo el crawler calcula y muestra la métrica de distribución de tipos de red. Determina el origen de la información sobre la propiedad de las IP y el significado de cada categoría actual; después, documenta las categorías acordadas, el método de recopilación y el comportamiento del tooltip de la UI como la Definition of Done.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Expected Behavior
Currently the crawler is pulling a count for the network types distribution metric which also doesn't necessarily explain a useful metric of what constitutes hosting vs. business as an example. Questions to be answered here:
- How does this currently determine what "type" of network this is? Just strictly IP addresses?
- Where does the information relating to who an IP address belongs to come from?
- What is the difference between hosting vs. business? I would argue it would be better to simplify this to {residential, business, government, education, unknown}.
If there's any data crawled that we see is useful for another category, let's add it.
It is a good metric to know how much of the network is being run on cloud service providers vs. home staking.
Current Behavior
Confusing and unknown how this metric is calculated and displayed.
Possible Solution
Let's figure out the best way to collect this information. We should be clear in how we are capturing this metric. It may be good to outline here how this metric is captured and create some sort of tooltip in the UI to explain what is being done to get this number.
- Lenguaje dominante
- Go
- Estrellas
- 60
- Forks
- 31
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ChainSafe/nodewatch-api
-
Configure DatadogQuizá libre de nuevo @priom la tomó hace 1426 días y no hay ningún pull request abierto. Abierto
ChainSafe/nodewatch-api#239 · 1 asignado ·
-
Add Basic MetricsAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
ChainSafe/nodewatch-api#231 · 2 reacciones ·
-
Excessive IP Data FetchingAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
ChainSafe/nodewatch-api#229 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
ChainSafe/nodewatch-api#211 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
ChainSafe/nodewatch-api#209 · 2 comentarios ·
Todos los issues de ChainSafe/nodewatch-api
Issues similares
-
automation models
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
txn2/mcp-data-platform#1984 ·
Los mantenedores suelen responder en 1 día
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Fix broken Code of Conduct linksAbiertokind/docs prio/P2
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
agent-substrate/substrate#1986 ·
Los mantenedores suelen responder en 1 día