Local blog for Spanish speaking developers in LATAM
Problemas, errores y trabajo acumulado
lunes, 16 de diciembre de 2019
Administrar los comentarios en proyectos grandes de código abierto como Flutter
En Google, siempre nos alegra ver el modo en que Flutter crece como un proyecto comunitario de código abierto. Ya sea en términos de
popularidad en GitHub
, cantidad de
proyectos creados
o
aumento de las habilidades
, el 2019 fue un año muy importante para el proyecto y queremos expresarte nuestra eterna gratitud por la ayuda y los aportes que hicieron de Flutter el proyecto que hoy es. Creamos Flutter contigo y para ti, y esperamos que eso se manifieste en todo lo que hacemos.
A medida que crecemos, también aumenta la cantidad de problemas que debemos controlar. Los problemas en GitHub no solo sirven para notificar errores, sino también para hacer referencia a cualquier unidad de trabajo del proyecto. Todas las personas pueden notificar errores y estos se clasifican en las siguientes categorías:
Solicitudes de funciones, que hacen referencia a aspectos que Flutter podría incorporar o mejorar.
Problemas de asistencia, es decir, preguntas de los usuarios sobre el funcionamiento de Flutter o lo que pueden hacer en el proyecto. Aunque es mejor formular estas preguntas en Stack Overflow, muchas mencionan también aspectos de nuestra documentación que podríamos mejorar.
Defectos legítimos, en otras palabras, elementos que no funcionan como deberían. Esto abarca problemas graves (como fallas y regresiones de rendimiento) y también esos pequeños errores molestos que suelen ocurrir en sistemas de software importantes.
Elementos no evaluados que no se analizaron ni etiquetaron.
Con esto queda demostrado que nuestros problemas no son solo una recopilación de defectos, sino que constituyen trabajo acumulado. Todo aspecto en el que deseemos trabajar debe representarse como un problema y etiquetarse correctamente. De este modo, tendremos un punto de partida para planificar nuestras metas y objetivos.
Algunos proyectos usan la cantidad de errores sin resolver como un parámetro para medir la calidad de las versiones y clasifican los errores como defectos o problemas.
Flutter no funciona así. Lo que hacemos es controlar los errores y problemas en el mismo lugar (GitHub) y no mantenemos nada en secreto
. En consecuencia, siempre serán más las tareas de las que
podríamos
ocuparnos que aquellas de las
que
nos ocupamos. Esto sucede con muchos proyectos de código abierto que funcionan bien; basta con echar un vistazo a los que están hace tiempo, como
Tensorflow
,
Chrome
,
Dart
,
Go
o
VSCode
.
Sin embargo, queremos asegurarnos de que los problemas que recibimos estén bien etiquetados y llevar adelante las tareas necesarias para que la base de datos de problemas refleje correctamente el estado de nuestro producto. A tal fin, nos involucramos con la comunidad y convocamos a un grupo de voluntarios que nos ayudan durante la evaluación inicial. Además, nos
complace anunciar que nos asociamos con Nevercode
, que son los proveedores de
Codemagic
(un sistema de IC/EC líder para Flutter) para que también nos ayuden con las evaluaciones iniciales.
El ciclo de vida de un problema
Siempre estamos dispuestos a recibir notificaciones sobre errores. En las
Pautas de evaluación
, describimos el proceso que usamos para evaluar errores. Así es como funciona en la práctica:
Un problema empieza contigo (usuario de Flutter) o con un colaborador del proyecto de código abierto. Una vez que lo notificas (lo mejor es que los errores incluyan casos reproducibles o las solicitudes de funciones detallen claramente qué propones y por qué), se envía a
la etapa de evaluación inicial
.
Durante esta etapa, un participante de la comunidad, como un voluntario, alguien de Nevercode o un ingeniero de Flutter, analiza el problema y formula varias preguntas:
¿Está claramente definido?
Si es un error, ¿incluye un caso reproducible e información suficiente para continuar?
Si es una mejora de una función, ¿entendemos bien qué pide el usuario para poder evaluar si constituye un aporte para la plataforma?
¿Ya se notificó este problema en el pasado?
A medida que hacemos esto, aplicamos la mayor cantidad posible de etiquetas al problema durante la evaluación inicial. Usamos las etiquetas de muchas formas, por ejemplo, para establecer la prioridad relativa, determinar cómo dirigir un problema a un equipo específico y decidir si hace falta incluir el problema en un objetivo futuro. Usamos las consultas de GitHub y algunas herramientas personalizadas para analizar los problemas en busca de elementos que indiquen qué busca la comunidad y por qué.
Luego, tiene lugar
la evaluación secundaria
, durante la cual un equipo asignado analiza el problema y formula preguntas, por ejemplo, cómo se adapta el problema al trabajo que realiza el equipo actualmente y cuándo pueden programar la finalización del trabajo. Nuevamente, se agregan o cambian etiquetas, ya que nos permiten obtener la mejor perspectiva sobre el trabajo que queremos hacer y quién puede hacerlo.
Con el tiempo, un ingeniero se ofrece a trabajar en el problema. A diferencia de muchos proyectos de software, no solemos asignar los problemas a colaboradores. En cambio, son los colaboradores (de Google o externos) quienes se ofrecen a abordar los problemas en lugar de que se los asignen a partir del trabajo acumulado. Al permitir que sean los desarrolladores quienes se ofrezcan, dejamos el equilibrio de carga en manos de ellos. Cada colaborador se asigna a sí mismo solamente los problemas en los que esté trabajando activamente y define objetivos para que podamos saber cuándo llegarán a la rama principal. Los líderes pueden pedir a una persona específica que se ocupe de un problema si así lo desean, pero, en definitiva, es solo eso: un pedido de ayuda, no un ultimátum ni una asignación.
Después de que estamos satisfechos con la resolución del problema, lo cerramos. Solemos incluir un vínculo a la solicitud de incorporación de cambios en la que se aborda el problema, pero también se cierran problemas por otros motivos, como los siguientes:
¿Se trata de una solicitud de asistencia? Si es así, dirigimos a la persona que envió la notificación a un canal de asistencia, como la lista de distribución de
flutter-dev@googlegroups.com
, el sitio de Reddit
r/FlutterDev
, nuestras comunidades de Discord (el
chat de usuarios
o el
chat de la comunidad
que usan principalmente los colaboradores) o
Stack Overflow
.
¿Ya se notificó antes este problema? Antes de cerrarlo, incluimos un vínculo al problema original y lo actualizamos.
¿Hay suficiente información para reproducir el problema y pudimos hacerlo? Si no es así, es muy probable que no podamos hacer nada y cerraremos el problema.
Nuestros avances hasta el momento
Como puedes imaginarlo, el aumento de nuestra popularidad trae aparejado más problemas abiertos y cerrados en
github.com/flutter/flutter
(donde se almacenan todos los problemas, salvo los del sitio web, que se registran en
github.com/flutter/website
):
Comparación entre errores cerrados y abiertos a finales de mes desde enero de 2018
También es notoria la cantidad de problemas que
no
tienen una etiqueta de uno de nuestros equipos de evaluación secundaria, como
marco de trabajo
,
motor
o
complemento
.
Problemas sin etiquetas de evaluación secundaria, de mayo de 2019 a la fecha
Se ve claramente cuándo empezamos a involucrar a Nevercode en el proceso de evaluación (a inicios de septiembre) y cómo se lograron avances importantes para mediados de septiembre cuando Nevercode se puso al corriente.
El énfasis en la evaluación es fiel reflejo de nuestra meta: en lugar de eliminar los errores
abiertos,
buscamos eliminar los errores
sin etiquetar
para que nuestra comunidad nos brinde los indicadores que necesitamos para priorizar mejor el trabajo. A medida que Flutter aumenta su popularidad, esperamos que siga creciendo el número de problemas abiertos que requieren evaluación, muchos de los cuales constituirán solicitudes de funciones nuevas enviadas por la comunidad. Seguiremos usando etiquetas como ayuda para determinar qué errores requieren atención inmediata, cuáles pueden esperar hasta nuestra próxima versión beta o estable, y cuáles son solicitudes de funciones nuevas.
¿Cómo puedes ayudarnos?
Una forma de ayudarnos es mantener organizada la base de datos de problemas solo con problemas que se puedan abordar. Cuando notifiques un problema, ten presente lo siguiente:
No uses GitHub si necesitas asistencia. Como parte del proceso de evaluación de problemas, cerraremos las solicitudes de asistencia publicadas en GitHub y redirigiremos a los usuarios a canales más adecuados. Es más probable que allí encuentres a alguien que pueda responder tu pregunta y es más fácil para otros usuarios encontrar preguntas y respuestas en estos canales.
Recuerda incluir casos reproducibles, especialmente si el problema es tuyo. Si no es tuyo, igual aceptamos casos reproducibles que puedas notificar. Escribir casos reproducibles de errores es una excelente forma de empezar a aprender a usar Flutter con ejemplos reales.
Actualiza problemas que te resulten importantes o súmate a ellos.
Aporta casos de prueba al repositorio de Flutter. Esta es otra forma de introducirte al mundo de Flutter y formar parte de la comunidad. También ayuda a evitar las regresiones; aunque todo el código nuevo viene acompañado de casos de prueba, intentamos aumentar la cobertura de las pruebas como práctica recomendada. Si te interesa colaborar de este modo, puedes echar un vistazo a los problemas con la etiqueta
a: tests
.
Considera ayudarnos a evaluar problemas que notifican otras personas.
Te agradecemos enormemente la ayuda y la confianza que depositas en nosotros al dedicar tu tiempo a Flutter y aportar tus ideas sobre aplicaciones. Nos encanta que la comunidad participe, ya sea notificando un error o una función que te gustaría ver, o creando una solicitud de incorporación de cambios para que Flutter sea la plataforma en la que quieres trabajar. ¡Gracias!
Labels
.app
.dev
.txt
#AMP
#CPU
#DeveloperStudentClubs
#DevFest
#DragonBall
#DSC
#Forsety
#ForsetySecurity
#freeandopen
#GCP
#Google
#GoogleCloud
#GoogleCloudPlatform
#GoogleLaunchpad
#iio2009
#Kubernetes
#MaterialDesign
#OneCommunity
#Security
#TensorFlow
#UPGlobal
#UpLatam
#WithGoogle
+page
10 YEARS
2013
2019
64 bits
A/B Testing
AA
Accelerator
Action on Goolge
actionbar
Actions
Actions Console
AdMob
Ads
adwords
adwords api
AI
AIY
ajax
alarmmanager
ALFA
almacenamiento
alojamiento de proyectos en google code
AMP
AMP Conf
AMP Project
amp-date-picker
amphtml
Analytics
Andorid
android
Android (operating System)
Android 3.1
android 3.3
android 4.2
android 9
Android 9 Pie
Android App Bundle
android design
Android Dev Summit
Android Developers
android Jetpack
Android P
Android SDK
Android Studio
Android Things
Android Wear
AndroidDevStory
androititlan
angelina jolie
Annotation
Announcements
anuncios
API
API Analytics YouTube
Apigee
APIs
Aplicaciones
aplicaciones chrome
app
app engine
App Indexing
app invites
App Server
applications
AppQuality
apps
Apps Script
AR
ARCore
arte
ATLAS
AWP
backend
Base64
batch
Bava
Betatesting
Better Ads Standars
bigdata
BigQuery
Biometrics
blink
bootcamp
BOT
BQ
Business
búsqueda ajax
by Google
byCases
byCommunity
byDevelopers
byGoogle
C++
CALENDAR
Cardboard
case
caso de éxito
Casos de éxito
casos destacados
CCOSS
Century Fox
chat
chrome
chrome web store
chromebook
chromecast
chromium
Cinéfilos
cloud
Cloud Anchors
CLOUD endpoints
Cloud Firestore
Cloud Functions
Cloud IoT Core
Cloud Next
Cloud Scheduler
Cloud services
cloud test lab
Cloud Text-to-Speech
Cloud Translation
CMD en vivo
coconut
code
code-in
code.org
CodeLabs
código
código abierto
Colab
colombia
Communities
Comunidades
concurso google
conference
contenedores
convocatoria
Coordinate
crashlytics
CRE
crear aplicaciones ajax
creatividad
Crowdsource
CSS
cws
daniela robles
dart
dart sdk
dartium
dartlang
Dataset
DCL
denis labelle
desarrolladores
Desarrolladores Google
desarrolladores LatAm
Desarrollar
Design
Design Sprint
Destacados
dev
Dev.f
DevArt
DevBus
DevBusLatAm
Developer Bus
Developer Summit
DeveloperConsole
developers
DevFest
devoxx
dialogflow
diseño UX
Distribuir
DNS
DOM
domain
DonkeyCar
doubleclick
Drive SDK
Drivers
ecommerce
ecosistema
elections
elizalde
Emoticons
emprendedores
empresas
engagement
english
Enhanced Campaigns
enterprise
eventos
Events
evolución de aplicaciones
Excel
ExpertosDicen
Faas
Family
FanBridge
FCM
FCP
Featured
fido
find people
Fintech
firebase
Firebase Cloud Messaging
firebase summit
flu trends
Flutter
Flutter 1.0
flutter 1.7
flutter developers
Flutter Live
FlutterLive
FoundersLab
Freebase
Fuction
Fuctions
Full-Stack
functional programming
G Suite Dev Show
G+
g+ goto gal
G+GotoGal
GAE
game
games
GCloud
gcm
GCP
GCS
GDA
GDE
GDG
GDH
GDL
GDLevent
GDS
Get Inspired
get.app
GitHub
GLP
gmail
golang
GOMO
Google
Google Accelerator
Google AdMob SDK
Google AdWords
Google Analytics
Google APIS
Google App Engine
Google Apps
Google Apps Script
Google Art Project
Google Assistant
google calendar
google cast
Google Charts
Google Chrome
Google Cloud
Google Cloud Console
Google Cloud Messaging
Google Cloud Next
Google Cloud Platform
Google Cloud Platform Newsletter
google cloud platforn
Google Cloud Storage
google code-in
Google Compute Engine
Google Dataset
Google Developer Groups
google developers
Google Developers Academy
google developers expert
Google Developers Hackademy
google dns
Google Drawings
Google Drive
Google Earth
Google for games
Google Forms
google geo
Google Home
google i/o
google i/o extended
google io
Google Keep
Google Kubernetes Engine
Google Launchapad
Google Launchpad
Google Maps
google maps coordinate
Google Maps Platform
Google Mexico
Google Nose
google now
Google Person Finder
google places api
Google Play
Google Play Books
Google Play Developer API
google play games
Google Play Movies
Google Play Protect
Google Play Services
Google Plus
Google Science Fair
google search
Google Sheets
google sign in
Google Top Geek
Google+
Google+ Communities
Google+ Hangouts
google+ sign-in
GoogleAPI
googlecloud storage
GoogleCloudPlatform
googledevs
GooglePlay
Googleplex
Goolge Lunchpad
GTG
Hackademy
hackers
Haiko
Haití
hangouts
Hangouts Remote Desktop
hardcode
Heello
honeycomb
HTML
HTML5
HTTPS
I/O
IA
IAM
IETF
IFAI
in app purchases
in-app
ingles
Ingress
instagram
integración de soluciones
interactive post
Interesante
International
International Women’s Day
IO
io15
io18
io19
iOS
IoT
istio
IU
IVR
J2EE
java
JavaScript
jelly bean
JS
JSON
Juegos
juegos html5
Kit ML
Knative
kotlin
kUBERNATES
Kubernetes
LATAM
latamRegionSur
Launchpad
Launchpad Studio
Lenovo Mirage Solo
lightbox
linux
lucero galindo
machine learning
Made with Code
Mapdata
Mapeo
maps
Maps Ad Unit
Maps API
Maps Engine
Market
Marketing
Marshmallow
MATERIAL DESIG
Material Design
mejores apps 2013
México
michelle marie
MIT
MIT Global Start-up Labs
MIT-AITI
ML
ML Kit
mobile
monetizar
mongoDB
MOOC
Motorola
Mountain View
móvil
MQTT
mr.white
mTLS
natalie villalobos
Navigation
NBA JAM
NES
Next Big Sound
Next Level
nfc
Niantic
Nik
NINTENDO
node.js
NoSQL
nube
OAuth2
Objective-C
OClock
open source
OPenApi
OS
OSS
Paas
PageSpeed
PagesSpeed
parallel18
patrones
patters
performance
permisos
Pipeline API
Pixability
pixel
Píxel
play
Play Console
Playtime
Podcast
pollito pio
Polymer
por lote
Posse
Prediction API
primer
Producto
programación
Propositos
Protocol Buffers
proyecto 20%
Push API
PYMES
python
Q
Q4
quickoffice
Rasberry Pi Zero WH
Raspberry Pi
Realtime
Reflectly
register
Release
Resources
robots.txt
Safe
SDK
Search
Security
seedbank
seguridad
SEO
servidores
Showyou
sign-in
SNES
SO
social media
Spain
SpLATAM
SQL
SQLite
Start
startup grind
Startup Launch
startup weekend
startup weekend for the planet
startupbus
startups
StayAtHome
story
Street View
subtitles
success
sw
SyScan
tablet
Tablet Optimization Tips
tabletas
takeaction
Tango
tendencias 2013
TensorFlow Developer Summit
testing
TextView
TF JAM
The Garage
The Venture City
tips G+
tips gmail
TLD
TLS
Top Experts
Top Geek
top level domain
TopExpert
topics
traducciones
Transparency Report
triggers
Tubular Labs
twilio
Tyka
TypeScript
UAC
udacity
ui
Umbrales
UNAM
unity
Unity3D
universal search
UX
Vector
VectorDrawable
video juegos
vidIQ
ViewPager
Visual Progress
Voicekit
VPC
VR
VSCode
web
Web hosting
Web móvil
WebAssembly
with google
Wizdeo
WizTracker
Women at Google
Women Techmakers
workmanager
WTM
XKCD
XML
Yifat Cohen
youtube
YouTube Analytics API
YouTube API
YouTube Data API
YouTube One Channel
YouTube Player API
Archive
2024
sept
2023
nov
oct
sept
ago
jun
may
abr
mar
ene
2022
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2021
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2020
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2019
dic
nov
oct
sept
ago
jun
may
abr
mar
feb
ene
2018
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2017
nov
sept
ago
jul
jun
may
abr
ene
2016
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2015
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2014
dic
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2013
dic
nov
oct
ago
jul
jun
may
abr
mar
feb
ene
2012
dic
nov
oct
sept
ago
jul
2011
nov
oct
may
mar
2010
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2009
dic
nov
sept
ago
jul
jun
may
abr
mar
feb
ene
2008
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2007
dic
Feed
Desarrolladores
Eventos y Comunidad
Casos Destacados
Dicen los Expertos
Google Accelerator