Another tool that can help the RFS workflow is PET [1], where we can see which packages are ready for upload.
But I like the pad idea :) [1] https://pet.debian.net/pkg-ruby-extras/pet.cgi 2016-03-10 2:20 GMT-03:00 Antonio Terceiro <[email protected]>: > On Wed, Mar 09, 2016 at 07:51:08PM +0530, Balasankar C wrote: > > On ബുധന് 09 മാര്ച്ച് 2016 09:48 രാവിലെ, Sebastien Badia wrote: > > > The idea of a permanent pad (in order to facilitate teamwork) came > > > during discussions. > > > > Good idea, _iff_ it doesn't replace the concept of RFS mails. I > > understand it will help DDs of the team get a list of unattended RFSs > > quickly and decrease the delay. But, pad should be there to only > > support the existing RFS workflow, which uses mails to the team > > mailing list, not replace it. > > > > Main reason is that reviews for RFS mails must be archived as they are > > great pointers for beginners and helpful when creating documentation. > > The reviews I got for my RFS mails helped me in future packagings and > > it happened because the mails get archived. > > > > Also, RFS mails is a good way for new members to get introduced to > > community and improve the bond between community members. > > > > So, I am all in for the idea, but will practice RFS Mail + Pad entry. :) > > ACK. Handling RFS through the pad was very useful in the sprint, but > now that we are all apart in terms of both space and time, the most > useful feature of a pad would be to know what RFS are being processed by > whom, so as a sort of coordination effort, i.e. to take notes on things > that are going on. > > -- > Antonio Terceiro <[email protected]> > -- Lucas Kanashiro
