From mehdi at dogguy.org Mon Mar 6 17:22:05 2017 From: mehdi at dogguy.org (Mehdi Dogguy) Date: Mon, 6 Mar 2017 18:22:05 +0100 Subject: [Debian-roadmap] Roadmap -- kick-off In-Reply-To: References: Message-ID: Hello, On 13/02/2017 20:54, ???????? ????? wrote: > > Hello, all. > > Herewith my comments. I am new to the internal of Debian DDs so please bare > with me on some of my maybe silly questions. > No problem. We don't bite. :-) > 1. Methodology (of RMTM management): > > I am not sure if we should strictly adhere to any management methodology. My > problem is not the methodology of choice but rather the task(s) at hand. We > will be dealing with the communication to/from multiple remote teams and > developers and we will have to manage our own work on that. > > And on top we will have to coordinate all those people's efforts. I don't > think this fits fully into any agile (or not) methodology. In my opinion > people will just have to take ownership of the goals and look to it that > they're moving forward. Sure we can use elements from different methodologies > (i.e. Kanban boards) but I don't think we will be able to use any single > methodology fully. > I totally agree. The role of the team is to to make necessary communication to gather ideas, encourage drivers to communicate about their ideas and ensure progress is made. The methodology is not very important. The only requirement is to have a clear/simple workflow. > Also, having in mind the nature of open source projects and the long-term > goals of the road-map team there cannot be any strict planning. I don't > believe we need such planning however I am mentioning this. > This is true. Vast majority of Debian contributors are volunteers. It is hard to expect them to commit on a strict deadline. But we also noted that leaving the deadline question completely open doesn't bring anything positive. I think that it is reasonable to ask them to show a reasonable deadline, but without putting too much pressure on it. If they are able to do that, they will try hard by themselves to meet the deadline. If it doesn't happen, then it might mean that the subject is more complex that they initially imagined. Having dates is also important if we are planning meetups or if there are dependencies between ideas. We don't need very precise and strict dates, but some idea on when it could be ready helps. > Anyhow reaching a set goal in our case will require multiple small (or sub-) > tasks for the coordination of everybody's efforts. Managing all this in our > day-to-day work demands some tool. As I am not closely familiar with the > available Debian infrastructure can someone state tools are available to us? > The question about tools is quite open. Some people started to use Kanban for DebConf related tasks. One can imagine using Debian's BTS (bugs.debian.org). > > 2. Ownership of goals:* > > I do agree there should be strong ownership of the goals. Advocates should > see to it that the goals are moving along and kept. @/martin f krafft /you > have a good point there about the transfer of ownership procedure. The > Roadmap team should be able to reassign ownership so that a goal is > finished. > > The procedure of transferring a goal to a new advocate should also involve > all the documentation of the item (tasks, what was done, what is to be done, > etc.). This is another reason to have a centralized place to store all this > information. If an advocate goes MIA with all the related information a goal > can quickly become not manageable. > Indeed. I do not expect advocates to have a documentation with all items, but we can ask them to prepare something with the most important things so that anyone else interested can join and contribute, not necessarily take over the goal. > What about goals that have no current advocates? Shall we keep a list of > such goals maybe motivating people to pick goals from it. > If there are people ready to pick up orphaned goals and work on them, then yes, why not? > > 3. Technical ctte partisipation > > How will we know the borders of the decisions that the roadmap team can > take? Will the Roadmap team be able to add items to the roadmap without any > participation of the ctte? I don't think this is possible. I just want to > ask who will take the decision to add a specific item to the roadmap or not? > The Technical Committee is there to help when a conflict happens and when we are not able to reach a consensus. (in short). They do not decide on which ideas are part or not of the roadmap. They offer advice and resolve conflicts. Their role is well described in the constitution: https://www.debian.org/devel/constitution#item-6 > 4. Item conversion to a release goal If a roadmap item becomes a release goal > does it fall outside of the jurisdiction of the roadmap team? > Definitely, Yes. > > 5. DEP process This is more of a question from me. Can you point me to the > documentation of the "DEP process"? > This: http://dep.debian.net/ It is quite nice but lacks people taking care of it. Kind regards, -- Mehdi