On 29/09/11 22:00, Garino Pierangelo wrote: Hi Juanjo, I got the same request (same person) for I2ND project. I think that would be worth sending the mail to the AB. Moreover, the reason to request joining the chapter project was ‘to submit GE request by Finest’: I believe the mail should also explain (maybe with the link to the relevant Wiki tutorial pages) what the UCPs can input, that is Feature requests in the FI-WARE backlog, not GEs. This was communicated several times ... but seems like there is some sort of misscomunication within some UC projects. Nevertheless, I'll send the message to the AB right now. Two more questions about the capability to monitor our chapter backlogs, as I’m a bit confused: - If we have e.g. one ‘public’ backlog per chapter, visible to everybody, can we also have the ‘private’ trackers in parallel to it, not visible to users outside FI-WARE? - Why should we have EPICs/features in the chapter backlog, aren’t they already in the FI-WARE Wiki backlog? I believe we could keep the single chapter backlogs private and devoted to the user-stories tracker(s) Did I mix something wrongly? Maybe I was the source of confusion because I have used the term "backlog" where I should have used the term "tracker" to be more accurate. Essentially, the model we are currently deploying is like this: * Full description of entries linked to the different FI-WARE Chapter Backlogs is posted in the public Wiki (MediaWiki instance linked to the FI-WARE project in FusionForge). Note that everyone in the world is able to read the Public Wiki. Only members of the FI-WARE project in FusionForge (and this include UC projects) can edit its contents. * Full description of entries linked to the Unclassified Enablers Backlog is also posted in the public Wiki, therefore accessible by anyone in the world. Again, only members of the FI-WARE project in FusionForge can edit its contents. * The "FI-WARE Feature Request" tracker is accessible to anyone in the world and also anyone in the world may create tickets. However, they cannot perform other operations on the tracker (assigning tickets to people, etc) . Tickets should include a link to a Wiki where the proposed backlog entry is fully described. * There will be a tracker "Backlog" at each "FI-WARE <Chapter>" project used for managing lifecycle of entries in that FI-WARE Chapter Backlog (at least, Themes, Epics and Features). Everyone in the world can read tickets in that tracker but cannot create tickets nor change them. * FI-WARE Chapter teams will be able to also create tickets linked to User-Stories at the "Backlog" tracker at each "FI-WARE <Chapter>" project in FusionForge. In that case, User Stories will be also publicly accessible. However, they are free to create another tracker(s) to deal with management of User-Stories separately from Themes/Epics/Features. Then they can configure these user-story oriented trackers to be private (just accessible for members of the "FI-WARE <Chapter>" project in FusionForge) The only point that is a bit risky is that we are allowing members of the FI-WARE project at FusionForge to edit the Wiki, and this includes the UC projects ... and we are allowing this not only for parts of the Wiki that clearly UC projects need to edit (e.g., the Unclassified Enablers Backlog part) but other parts as well. If we don't trust they will not change anything that we maintain (Product Vision, Tutorials, etc) then we will probably had to combine two Wikis, I'm afraid ... Why do we want to keep a "Backlog" tracker at each "FI-WARE <Chapter>" project in FusionForge, if full description of entries of that FI-WARE Chapter Backlog are already recorded in the Wiki ? Aren't we repeating things twice (record the entry in the Wiki and in the tracker) ? Well ... because of the following: * The tracker helps us to handle assignments of entries to people in a more easy and flexible way * The way you keep track of history and trace changes in a ticketing system is more convenient than in a wiki. You may even monitor tickets or even entire trackers so that changes are reported to you via email. * You can more easily attach documents to tickets as well as establish "conversations" around tickets * You can link tickets to tasks, thus applying Agile methodology beyond management of backlogs * Personally, I believe it will be easier to present backlogs to reviewers and the external world browsing trackers than browsing wiki pages. Best regards, -- Juanjo BR Pier Da: fiware-wpl-bounces at lists.fi-ware.eu<mailto:fiware-wpl-bounces at lists.fi-ware.eu> [mailto:fiware-wpl-bounces at lists.fi-ware.eu] Per conto di Juanjo Hierro Inviato: giovedì 29 settembre 2011 20:11 A: Alex Glikson Cc: fiware-wpl at lists.fi-ware.eu<mailto:fiware-wpl at lists.fi-ware.eu>; fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> Oggetto: Re: [Fiware-wpl] Fw: Request to Join Project FI-WARE Cloud Not sure you can add a message in the rejection ... I'll ask. Nevertheless, I will send an email to the FI-PPP AB mailing list (where representatives of all UC projects are registered) telling them that we will reject any request to join to projects different than the FI-WARE project. Probably they are asking to join because they need to be able to "read" the trackers linked to Chapter backlogs. But this is something we will allow anyone world-wide (that is my recall on the matter when we discussed it, but it's also what makes sense to me), therefore they will be able to monitor. What they won't be able to do (and they shouldn't) is to submit tickets directly to the Chapter backlogs. Some people may argue that we shouldn't even allow "observers" to read our chapter backlogs ... Well, I believe that publishing Epics/Features is not a big deal and we have to keep them publicly readable. I would even add that not doing so could bring some troubles to us in front of the EC (I believe it would not comply with what we committed in the DoW) On the other hand, I would be more flexible regarding User-stories and leave to chapter partners the decision about keeping user-stories in separate trackers (either a single one or one per GE) or not. It would then be feasible to keep such user-story oriented trackers fully private. The trade off, of course, is that such approach would mean more administrative burden for the chapter partners, but if they wish to live with that, it's fine to me. Best regards, Juanjo Hierro Chief Technologist on Software Technologies Telefonica R&D Labs email: jhierro at tid.es<mailto:jhierro at tid.es> phone: +34 91 48 32932 www.tid.es<http://www.tid.es> twitter.com/JuanjoHierro Oeste 1, Planta 5. Distrito C Ronda de la Comunicacion s/n Madrid 28050 Spain On 29/09/11 19:33, Alex Glikson wrote: Dear Juanjo, Is there a way to reject a request to join a project with a comment/explanation? I've rejected the request below, but wanted to clarify that GE requests should be opened against the 'root' FI-WARE project. Regards, Alex P.S. copying WP leads, as similar questions are likely to arise for their WP projects in Forge ----- Forwarded by Alex Glikson/Haifa/IBM on 29/09/2011 08:29 PM ----- From: noreply at forge.fi-ware.eu<mailto:noreply at forge.fi-ware.eu> To: Alex Glikson/Haifa/IBM at IBMIL Date: 29/09/2011 05:06 PM Subject: Request to Join Project FI-WARE Cloud ________________________________ Nazila Gol mohammadi has requested to join your project. You can approve this request here: https://forge.fi-ware.eu/project/admin/users.php?group_id=14 Comments by the user: I need to join to this project in order to submit GE request by Finest ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:part1.05040805.06010600 at tid.es]Rispetta l'ambiente. Non stampare questa mail se non è necessario. ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110929/786314e6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 677 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110929/786314e6/attachment.jpe>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy