Local blog for Italian speaking developers
Problemi, bug e lavoro pianificato
25 dicembre 2019
Pubblicato da
kf6gpe
Gestione dei feedback in un grande progetto open source come Flutter
La crescita di Flutter come progetto open source guidato dalla community è motivo di gioia continua per noi di Google. Sia esso misurato in
popolarità su GitHub
, numero di
progetti creati
o
crescita delle competenze
, il 2019 è stato un anno determinante per il progetto e saremo sempre grati a tutti voi per il supporto e i contributi che ci hanno consentito di rendere Flutter il progetto che è oggi. Creiamo Flutter con te e per te e speriamo che questo sia percepibile in tutto ciò che facciamo.
Siamo cresciuti tanto ed è cresciuto anche il numero di problemi di cui dobbiamo tenere traccia! Utilizziamo gli issue su GitHub in vari modi: non solo per segnalare bug, ma per qualsiasi unità di lavoro relativa al progetto. Chiunque può inviare un issue e tali issue rientrano in una serie di categorie:
Richieste di funzionalità: cosa un utente o un contributor desidera trovare in Flutter o quali funzionalità migliore.
Richieste di supporto: domande degli utenti su come funziona Flutter o su come eseguire determinate operazioni. Sebbene sia meglio inviare queste richieste su Stack Overflow, molti utenti ci indicano anche come migliorare la nostra documentazione.
Difetti bona fide: cose che non funzionano come dovrebbero. Ciò include gravi problemi come arresti anomali e regressioni delle prestazioni, ma anche quei fastidiosi bug “fit-and-finish” che sono comuni in qualsiasi sistema software di grandi dimensioni.
Elementi non sottoposti a triaging che non sono stati esaminati ed etichettati.
Quindi, i nostri issue non sono solo una raccolta di difetti: rappresentano il lavoro che dobbiamo svolgere. Tutto ciò a cui pensiamo di voler lavorare dovrebbe essere indicato come un issue e opportunamente etichettato in modo che, mentre pianifichiamo i nostri obiettivi e i traguardi intermedi, abbiamo un punto da cui partire.
Alcuni progetti utilizzano il numero di bug aperti come indicatori per misurare la qualità delle versioni e classificano i bug come difetti o issue.
Flutter non lo fa; scegliamo di tenere traccia di bug e issue allo stesso modo, in GitHub, mantenendo alla luce del sole
. Di conseguenza, ci saranno sempre molte più cose su cui
potremmo
lavorare di quelle sui cui
stiamo
lavorando. Ciò vale per molti altri progetti open source; basta osservare quelli attivi da un po’ di tempo come
Tensorflow
,
Chrome
,
Dart
,
Go
o
VSCode
.
Tuttavia, vogliamo essere sicuri che gli issue in arrivo siano ben etichettati e di fare il necessario lavoro di “pulizia” in modo che il nostro database degli issue rifletta accuratamente lo stato del prodotto. A tal fine, abbiamo chiesto aiuto alla community: ci sono diversi volontari che ci supportano per il triage di prima linea e siamo
lieti di annunciare che abbiamo stretto una collaborazione con Nevercode
, i fornitori di
Codemagic
, un sistema leader di CI/CD per Flutter, per ulteriore supporto nel triage di prima linea.
Il ciclo di vita di un issue
Siamo sempre pronti a ricevere nuovi issue! Il processo di triaging degli issue è descritto nelle
Linee guida per il triage
. Ecco come funziona in pratica:
Un issue inizia da te: un utente di Flutter o un contributor open source. Dopo averlo presentato (si spera con un caso riproducibile se si tratta di un bug o una descrizione chiara di cosa stai proponendo e perché se è una richiesta di funzionalità), si passa al
triage di prima linea
.
Nel triage in prima linea, un partecipante alla community (un volontario, qualcuno di Nevercode o un ingegnere che lavora su Flutter) esamina l’issue inviato e pone diverse domande:
È definito chiaramente?
Se si tratta di un bug, ha un caso riproducibile e informazioni sufficienti per essere portato avanti?
Se si tratta di un miglioramento delle funzionalità, siamo in grado di comprendere sufficientemente ciò che stai chiedendo in modo da poter valutare il suo contributo alla piattaforma?
È un duplicato di un issue già presentato?
Mentre eseguiamo queste attività, il triage di prima linea applica quante più etichette possibile all’issue. Utilizziamo queste etichette in molti modi, ad esempio per stabilire la priorità, determinare come inoltrare un issue a un determinato team e se includerlo nel prossimo milestone. Utilizziamo le query di GitHub e alcuni strumenti personalizzati per analizzare gli issue e individuare eventuali segnali su ciò che la community sta cercando e perché.
Da qui, si passa al
triage secondario
, in cui un team assegnato esamina l’issue e pone domande, ad esempio se l’issue può essere inserito nel lavoro in corso e quando è possibile pianificare il completamento del lavoro. Anche in questa fase possono essere aggiungete o modificate etichette, in quanto le etichette ci forniscono le migliori istantanee possibili sul lavoro che vogliamo portare a termine e su chi può farlo.
Infine, un ingegnere si offre di lavorare sull’issue. A differenza di molti progetti software, in genere non assegniamo gli issue ai contributor: indipendentemente dal fatto che un contributor lavori per Google o meno, sono i contributor che si offrono di risolvere gli issue, non vengono loro assegnati dal lavoro che abbiamo pianificato. Consentendo agli sviluppatori di offrirsi, distribuiamo il bilanciamento del carico ai singoli contributor; ogni contributor si auto-assegna solo gli issue su cui sta lavorando attivamente e fornisce milestone a tali issue in modo che sappiamo quando finiranno sul ramo master. Ovviamente, i lead possono chiedere a determinate persone di lavorare sugli issue, ma il più delle volte è solo una richiesta di aiuto, non un ultimatum o un incarico.
Una volta che un issue è stato completato con nostra soddisfazione, viene chiuso. Spesso questo include un link alla richiesta pull che risolve l’issue, ma un issue può essere chiuso anche per altri motivi, tra cui:
È una richiesta di supporto? Indirizziamo l’utente che ha inviato la richiesta verso un canale di supporto come la mailing list
flutter-dev@googlegroups.com
, il
r/FlutterDev
Reddit, le nostre community Discord (
chat utente
,
chat community
utilizzata principalmente dai contributor) oppure
Stack Overflow
.
È un issue duplicato? Prima di chiuderlo, inseriamo un link all’issue originale, aggiornando anche tale issue.
L’issue ha informazioni sufficienti per essere riprodotto e siamo riusciti a riprodurlo? In caso contrario, è possibile che non possiamo fare nulla se non chiuderlo.
I nostri progressi finora
Come puoi immaginare, poiché la nostra popolarità è cresciuta, anche il numero di issue aperti e chiusi è aumentata
github.com/flutter/flutter
(questo contiene tutti gli issue tranne quelli relativi al sito Web, registrati in
github.com/flutter/website
):
Bug chiusi o aperti in base ai fine mese da gennaio 2018
Altrettanto entusiasmante è il numero di issue che
non
reca un'etichetta corrispondente a uno dei nostri team di triage secondari, come ad esempio
framework
,
engine
o
plugin
:
Issue non etichettati per il triage secondario, marzo 2019-oggi
Puoi vedere chiaramente dove abbiamo iniziato a coinvolgere Nevercode nel nostro processo di triage, all'inizio di settembre, avendo ottenuto grandi progressi già da metà settembre.
Questa enfasi sul triage riflette il nostro obiettivo: non avere zero issue
aperti,
ma avere zero issue
senza etichetta
in modo da avere segnali adeguati dalla nostra community e poter definire le giuste priorità al lavoro da completare. Mentre Flutter continua a crescere in popolarità, prevediamo una crescita continua del numero di issue aperti che richiedono il triage, molti dei quali saranno richieste di nuove funzionalità da parte della community. Continueremo a utilizzare le etichette per determinare quali sono i bug che richiedono attenzione immediata, quali quelli che possiamo rinviare alla prossima versione beta o stabile e quali sono le nuove richieste di funzionalità.
Come puoi aiutarci
Puoi aiutarci a mantenere il nostro database degli issue pulito e ordinato inviando issue utili. Quando invii un issue, ricorda quanto segue:
Non utilizzare GitHub per richieste di supporto. Come parte del triage degli issue, ora chiudiamo le richieste di supporto inviate in GitHub, reindirizzando le persone verso canali migliori. In quei canali probabilmente troverai qualcuno in grado di rispondere alla tua domanda e le domande e le risposte sono più facili da individuare anche per gli altri utenti.
Invia casi riproducibili: se è un tuo issue, assicurati che ce ne sia realmente uno. Anche se non è un tuo issue, valuteremo volentieri anche casi riproducibili inviati da te! Scrivere casi riproducibili per i bug è un ottimo modo per iniziare a imparare a usare Flutter con esempi reali.
Aggiorna e vota gli issue importanti per te.
Contribuisci ai casi di test nel repository Flutter. Questo è un altro modo per migliorare la tua conoscenza di Flutter e interagire con la community. Ci aiuta inoltre a prevenire le regressioni: mentre tutto il nuovo codice è accompagnato da casi di test, come buona pratica ci impegniamo anche ad aumentare la copertura dei test. Se sei interessato a contribuire in questo modo, puoi dare un'occhiata agli issue con l'etichetta
a: tests
.
Puoi aiutarci con il triaging di issue presentati da altri utenti.
Siamo profondamente grati per il supporto e la fiducia che ci hai dimostrato nell'investire il tuo tempo e le tue idee applicative con Flutter. Accogliamo con favore il coinvolgimento della community, sia che si tratti di inviare bug o richieste di funzionalità o di creare una richiesta pull per rendere Flutter la piattaforma con cui desideri lavorare. Grazie!
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly