Re: Debian Project Leader Elections 2019: Call for nominations
(Dropping Chris from CC: as he is subscribed to -vote) On 2019-03-12 16:55, Paulo Henrique de Lima Santana wrote: Mehdi, would you like to run again? I saw you run in 2017 and you have experience as DPL. I am really not sure what people are expecting from the DPL. My past experience showed me that expectations varied a lot between different groups/team/persons. Having a DPL elected doesn't mean people agree with his/her program. I am not sure what kind of governance the project needs today. We should collectively think about this before rushing someone to invest all his emotional and physical energy for one year. -- Mehdi
Re: having public irc logs?
On 08/04/2017 12:32, Gianfranco Costamagna wrote: > the problem is not having access to the logs, the problem is having a > "common/shared way of doing it" It would be mostly fine even to just have a > password protected irc log server, only accessible to DDs. > It is not totally the same though. IRC lists people in channels. Most of the users are not bots. So it is fine people record channel's activity as long as they are listed as present in channels. It tells us who is able to read channels conversations. People not there cannot. Putting logs on a servers (even password protected) changes this logic. Putting an IRC logger is really fine as long as you keep logs for you exclusive personal use. Also, putting logs on a server contradicts your point below. Why would Debian servers be less subject to cyber attacks than yours? Thinking about it, it is even the contrary, IMO. > […] >> There are simple technical measures that you could personally put in place >> to follow some channels. > > Yes sure, just I have some bad feeling about doing so. I can put a server in > place, what would happen if the server gets hacked and conversations put out > there? How can I prevent a server running 24/7 from being super secured when > opened with an online access? > Same could happen with your personal machine. The problem is not specific to remote servers connected to internet. Also, as said above, same could happen with an official Debian server. > lots of people are already logging irc conversations, the probability of > leaks increase with the number of people doing that. Security might also mean > to have a single point of sharing knowledge, not a lot of them. > The issue at hand is not technical, really. We only assess that logs belong to anyone present in the channel. It is personal, and not a common property. If you want to follow the discussion, you can join the channel. At least, that's how I understand it. Also, one may argue that discussions happening at DebConf are even more important than the few conversations we have on IRC. Yet, we do not record conversations happening outside talk/BoF rooms. -- Mehdi
Re: Q to Mehdi: safe and fun
On 06/04/2017 19:17, Holger Levsen wrote: > On Sat, Apr 01, 2017 at 11:52:51PM +0200, Mehdi Dogguy wrote: >> On 31/03/2017 12:38, Holger Levsen wrote: >>> On Fri, Mar 31, 2017 at 04:00:49AM +0200, Mehdi Dogguy wrote: >>>> If you want to ban someone from a mailing list, you may contact >>>> list-masters. >>>> If you want to ban someone from IRC, you may contact IRC operators. >>>> if you want to ben someone from the project, you may contact DAM. >>>> If you contact the DPL, then you're asking for some mediation. >>> >>> I must say I'm disappointed by this response in the context of debconf-team… >> Can you please clarify what you find disappointing and why here? > > in the case "of debconf-team", I dont think banning $that person from the > lists or from irc would be appropriate (one can be very very annoying and > yet not violating any rules) and offering mediation by the DPL *now*, after > several people left or severely reduced their involvement, is also way too > late. > Ok, thank you for the clarification. FWIW, as you guessed, I was recalling the role of DPL in such situations. Everyone has the right to ask for expulsions. It is up the team in charge to decide on the matter. I agree that the issue at hand should have been dealt with in 2014 or 2015 (where most of the damage was done). But we cannot cross arms and wait until things move away. I still believe we can find an acceptable solution for both parties (which doesn't mean both stand on their initial position and we are able to find magical solutions…). So discussing with both is still useful. (at least IMHO). So "way too late" (maybe yes) but still not useless! -- Mehdi signature.asc Description: OpenPGP digital signature
Re: having public irc logs?
On 07/04/2017 16:21, Gianfranco Costamagna wrote: > (this question was on debian-vote by purpose, and was directed to DPL, > I'll drop -vote on the next email) > >> (Replies redirected to debian-project, since this has nothing to do >> with the DPL election anymore.) > > > sigh, I agree > (I would have used -devel to have a public discussion, this wasn't > the case, but meh, it is nice to discuss such things anyway) > >> I guestion the usefulness of IRC logs for that kind of thing. The log >> shows that, say, a package was discussed three hours ago. Has the >> situation changed? It might have, but without anyone mentioning it on >> IRC, and therefor in the log. The kinds of things that are discussed >> on IRC tend be quickly changing. Logs are not useful for those. In my >> opinion and experience. > > > I had many times written something just some minutes after somebody else. > You might question it, I might agree with you, but in my life I have a lot > of use-cases of this being useful > (e.g. my uploads not being accepted, a quick look on -ftp channel logs > can show signs of dak sadness). > > But anyway, I don't see any added value of discussing what I find useful > and what you find useful :) >> This does not match my observations of reality. People seem happy to >> behave quite badly using their own names in public fora as it is. >> Making IRC channels public is unlikely to have much effect on >> behaviour. > > > completely correct, this was an answer to some "hey we can't public > logs because people are using bad words here". >> If it did, nobody would be an ass on Facebook, Google+, or Twitter >> unless they've taken care to hide their identity well. Yet people are >> posting, using their real names, sexist and racist slurs, even death >> threats. Not to mention newspapers and TV. > > > sigh, true, unfortunately nobody seems responsible anymore for > his behaviour. > >> If there's a problem with how people behave on IRC, that should be >> addressed directly. > > > sure, but this is not something I have to discuss, I don't have such > problem, I just think logs are useful :) > >>> You want to protect privacy but you know privacy doesn't exist on >>> public places. >> I disgree strongly. >> >> If I sit on a park bench with a friend and we discuss something, we >> have an expectation of privacy. If you record our conversation and >> play it on the radio, you've violated our privacy. > > > true >>> (it would be nice if some removed developer going away after some >>> bad flame war over Debian would publish *all* the logs just for fun) >>> How will you protect the privacy then? >> >> You're suggesting that someone publish non-public discussions? Becuase >> it would be fun? Seriously? > > > I didn't suggest that, but privacy online is seriously something that > *doesn't* exist, and people not understanding that are simply wrong. > you can have some false idea of privacy online, the website gets > hacked, or a bug shows logs on the server, or somebody else hacks > your pc. > In a park the damage you can do is limited, online is really worse the > situation > > (I remember some leaks of some websites for adults, leaking real email > addresses > and real passwords) > > > so, saying "somebody violating my privacy is wrong", when "somebody" can be > "null" or > "really difficult to track because vpn/tor", doesn't protect you much more. >>> People should be responsible for what they say, regardless where >>> they say. We are not kids anymore. >> I'll be sending a handyman to install a webcam and microphone in your >> bathroom and bedroom. I've also engaged a private investigator firm to >> follow you and record all discussions you have with friends. The ones >> that mention or refer to Debian will be posted to >> meetings-archive.debian.net. A team of volunteers will transcribe them >> and post them to identi.ca. After all, ýou need to be responsible for >> anything you say, at any time, in any place, in any context. > > > well, bathroom and bedroom are more private than irc I would say, but > sometimes even the context has to be considered when saying something > >> More constructively... if you have a point that specific disucssions >> about, say, release management should be made more public, then make a >> specific suggestion about that, with justificiations why it's a good >> idea. Saying that all Debian IRC channels should be logged publically >> is too broad to be acceptable to a large number of people. > > > And finally the point is there. > If you look closely to my first email I never said "all", and specially > I don't care about many channels (even -devel or -mentors might be useless > when not connected to the internet). > I even provided a list, -release, -ftp, -buildd. > > so, the question still stands. > Dear DPL candidate, how do you feel about having *some* irc channels of public > interest being available for offline users? > I feel bad about that. As
Re: having public irc logs?
On 06/04/2017 10:44, Gianfranco Costamagna wrote: > Hello Mehdi and Chris, > > > > Debian has a "we don't hide things" wording in his constitution. > > > However we don't have a public irc log system, and most > > > of the conversations between us are happening there. > > > > How do you relate to that issue? Do you see it as a problem, > > > or do you think people should join irc to read our conversations? > > > (channels protected by a passphrase are of course out of this question). > To be honest, I also wondered why IRC channels were not logged when I started contributing to Debian. Later, I understood that people used IRC to communicate like they would do in real life. As such, we will not try to record every conversation held between two contributors. I understand it is not easy to follow IRC channels. Many things are said out there. Many of what is said there can be found on mailing lists as well. You may install a permanent IRC client that would record some targeted IRC channels' activity, as pointed out by martin. I also agree what others have said in this thread. -- Mehdi
Re: Q to Mehdi: S.M.A.R.T. metrics
Hi martin, On 08/04/2017 09:13, martin f krafft wrote: > also sprach Mehdi Dogguy <me...@dogguy.org> [2017-03-30 02:13 +0200]: >> I do not remember myself talking about S.M.A.R.T criteria in personal >> discussions to be honest :-) or if it ever happened, maybe it was >> because it was mentioned in my platform and elsewhere. > […] >> But anyways... I am not particularly fond of S.M.A.R.T criteria >> […] > > How do you reconcile these two statements? Why do you want your > roadmap to consist of S.M.A.R.T. items? > My statement is *not* "I do not like S.M.A.R.T". I explained in my previous mail why it is relevant to use it to follow roadmap goals. It helps us to measure progress of each goal. >> In general, I have followed the same methodology for all subjects >> I've worked on during my DPL term: I have installed a kanboard [2] >> instance on my server ; created a project (let's call it DPL) and >> created tasks for every subject. Depending on the nature of >> subject, I added sub-tasks sometimes. Comments were also used to >> track the progress of the task. > > Would you see any value in having this publicly visible on official > project resources? > Of course. I can. But, I didn't find a way to leave some tasks in "private" mode though. And I consider it a blocker. Instead of migrating my current setup, I can try to use a public instance in the future. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to both: release date
On 2017-04-05 10:18, Chris Lamb wrote: Dear Lucas, is there something that you would like to stress about the release process or the upcoming release? I think I would highlight that these indeed *are* outside the scope of the DPL, implicitly stressing Debian's decentralised nature; this structure makes Debian unique and very attractive for all sorts of use-cases so we shouldn't be justifying or apologising for it. It is true that Debian is decentralized but it is also true that subjects are handled in a transparent way. So any project member familiar with teams' processes is able to find references online and give an idea on how things are going on. This can be done without stepping on someone's toes. So based on that, it becomes even more interesting to give a point of view from an outsider since it might give others a few interesting pointers: - how Debian judges the quality of its releases, which metrics are used - what are the most important components and milestones of a release - what is the release process - what kind of tools Debian is using to follow progress of the freeze It is not necessary to make a detailed description of each tool but it helps many people to have this overview and be able to dig into each subject autonomously. I believe such a report helps others to understand our work and potentially where they may contribute. Doing so, one should remember to not give any conclusion or anything that looks like a decision and must refer to the Release Team for an official position/statement. I think these things are more important and more interesting to communicate than a laundry list of version numbers of the major software packages that we plan to release with. I think lucas was not asking for the content of "What's new" section of the Release Notes. My understanding is that he was more interesting in our way to evaluate progress of a subject with an external point of view. Asking teams about status of a subject is a way, but being able to make our own point of view before engaging in a discussion can also be helpful and gives us (maybe) a different perspective. This can be summed up in a single point: understanding how teams work. It is not obvious since we have different kind of teams (core, development, translation, communication, project management, event organization, etc…). Each kind of team has its own workflow and set of tools. Regards, -- Mehdi
Re: Q to both: release date
Hi lucas, On 2017-04-05 09:17, Lucas Nussbaum wrote: How is the release process doing? As noted by Chris too, the Release Team has all the details and can reply on this specific question. I've pinged them about issuing a status update on the freeze and proposed my help write/review the mail. Looking at the numbers, the Release Team is doing quite well (as always). They seem to be able to process unblock requests quite quickly. Kudos for the Release Team! Last update from a member of the team dates back to February: https://nthykier.wordpress.com/2017/02/04/the-stretch-freeze-is-coming/ Since then, some blockers were resolved (stretch-backports area created, gcc-5 removal done, openssl transition (mostly)). Release Managers are keeping a checklist up-to-date on: https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/StretchCheckList We've had a 2nd release candidate of the installer. So, globally, it looks like it is going okay. I think that the Release Team can be helped with more rc-bug squashers. There are also some BSPs coming soon. So I guess it would help to deal with a few issues. What is your guesstimate for the release date? “When it's ready!“, of course :-) I am sure members of the release team (and especially release managers) have an idea of which date (or period of time) to target for the release date. They didn't disclose it. So I do not see a reason to do so on my side. It would counter-productive and would send a bad message to people following this mailing-list (as it could be taken as an announcement, no matter the size of the warnings you could put in the mail). I trust the Release Team to do a stellar job at handling this freeze cycle, as always. If you were asked that in a press interview, is there something that you would like to stress about the release process or the upcoming release? Testing, Squashing RC Bugs, Reporting issues early. -- Mehdi
Re: Q to both candidates: preventing burnout by other contributors
Hi Russ, Sorry for the late reply. On 29/03/2017 18:33, Russ Allbery wrote: > 1. Do you agree with the above analysis, or do you see a different >dynamic? > I agree with your analysis. But even in companies, there are issues and not all managers are able to deal with them. And really, it is not always because of managers' skills. There are cases really difficult to deal with, and require some help from qualified persons. > 2. Do you have any thoughts or plans around how to more proactively >address social problems that fall short of explusion but that will >require some teeth and actual consequences to get at least one of the >parties to be willing to change their behavior? Some simple solutions like a phone call before a social event to check the intentions and plans of the person. If we are speaking of cases that fall short of expulsion, this could help to prevent new issues. A temporary ban from event or from Debian systems could also be dissuasive depending on the issue at hand. The idea is to show that misbehavior will not be left unpunished. -- Mehdi
Re: Question for DPL candidates: Teetotaler outreach
Hi Adrian, On 31/03/2017 16:36, Adrian Bunk wrote: > Hi, > > first of all thanks a lot for running. > > Both of you consider outreach important. > > People not drinking alcohol are half of all adults in the world, but > we are under-represented in free software. Unfortunately far too many > people mistake alcohol for a social lubricant, and might not even notice > that for many people terms like "beersigning" do not at all sound like fun. > > How do you plan to create a more welcoming environment for people not > drinking alcohol, and reach out to teetotalers? > First, thanks for asking this question! I do not drink alcohol myself. And I have to admit that I never felt unwelcome during Debian events or even those advertised as "beersigning". I've always substituted "beer" with "beverage" in mind when reading it in announces. Event organizes have been careful enough to provide non-alcoholic alternatives, even during "Cheese and Wine" parties. I agree that we should avoid advertising events by highlighting the fact that there will be beers (or other sorts of alcohol). We should not be encouraging drinking alcohol, nor use it to attract people to social events. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to both: facilitating meetups
Hi zack, On 31/03/2017 10:29, Stefano Zacchiroli wrote: > On Fri, Mar 31, 2017 at 01:44:59AM +0200, Mehdi Dogguy wrote: >> Hope this answers your questions. > > So, here's a straw man for you: considering the roadmap failed to > materialize during a 1-year term, how confident you are it will > materialize during a second term? > Very. :-) More seriously… I think I've a done a fair bit of promotion around this program (and I am sure it is still needs some more efforts). The concept of the roadmap is similar to release goals. The latter is well known to project members. So I do not expect them to reject it. The most difficult point with the roadmap, IMO, is to create the right team which would take care of this activity in the long term. In order to not put this idea at risk, I intend to work on this myself. > And given you seem to argue that it did not materialize during the first > year because it was a "leading to a release"-year (which is a sensible > argument, IMO), how periodically do you think the Debian project will > manage to update such a roadmap in the long run? Once per release cycle? > All roadmap items will not necessary be bound to a release. So the rhythm of the roadmap will not follow release cycles. It is reasonable to think that we will be able to do an annual review of the roadmap (i.e. a report on the progress of each item, an opportunity to include new items or to drop a few, a call for help for a few items that we need to boost). During freeze periods, the roadmap team can publish a specific report about items implemented during the development cycle and the ones that might need a little push to make it in the current release if still feasible. -- Mehdi
Re: Q to Mehdi: safe and fun
Hi holger, On 31/03/2017 12:38, Holger Levsen wrote: > On Fri, Mar 31, 2017 at 04:00:49AM +0200, Mehdi Dogguy wrote: >> If you want to ban someone from a mailing list, you may contact list-masters. >> If you want to ban someone from IRC, you may contact IRC operators. >> if you want to ben someone from the project, you may contact DAM. >> If you contact the DPL, then you're asking for some mediation. > > I must say I'm disappointed by this response in the context of debconf-team… > Can you please clarify what you find disappointing and why here? > Banning someone is a last step, what's lacking are steps before that. > > Granted mediation *is* a step before banning, but IMO it didnt work well in > the context of debconf-team… though "didnt work well" is a very mild way to > put it :-( > > Also, I think mediation was tried way too late (=years), after several team > members burned out, left and were not interested in mediation anymore. > > (Sadly I have not much constructive to say here right now…) > > signature.asc Description: OpenPGP digital signature
Re: Q to Mehdi: safe and fun
Martin, On 29/03/2017 07:58, Martín Ferrari wrote: > Mehdi, > > In your platform you list "Ensuring the community remains safe and fun" > as your first priority for the next term. > > I need to ask why you think in this term you will manage to do so, when > I believe you failed to do so in the last year. > I think you are being unfair here. You can read my reply to madduck's question on the same subject "safe and fun". But as a reminder of a few points: - I was able to restaff the AH team quickly and do regular pings to ensure it remains functional - I am really optimistic the AH team will be able to publish regular reports - The new DebConf Committee delegation is working properly and I do not see major issues putting DebConf or Debian's finances at risk - I have encouraged sprints, BSPs, acquisition of hardware, etc... and worked on simplifying a bit the reimbursement process. - I have automated production of DD certificates and thanks to nm.d.o's notifications, I contact every new DD to make sure they get all the attention and help they need. - I have organized multiple sessions at DebConf to make sure important subjects get some attention. And I am pretty sure I'll have new ideas to implement or suggest with time. So stating that I failed is a bit harsh, IMHO. > Some context for the rest of the readers. > > For many years, my main involvement in Debian has been helping with > DebConf. I was delegated as DebConf Chair by Lucas in August 2014, a > position I held until October 2015 when all three chairs resigned in block. > > I resigned because I could not withstand the burnout any more, the > sleepless nights, and being in anger all the time. > > For me, all that harm came mostly from one determined person, and a few > followers. Many current and former DebConf-team members agree with this > diagnosis. > > This person, and a couple others can be blamed directly for the burnout, > resignations, and vacations many valuable volunteers took during my tenure. > > > The DPL at the time knew about this, but he did nothing to improve the > situation. > > After you were elected as DPL, me and many other people spent loads of > time discussing with you the problems within DebConf: political and > personal. > In fact, this is not really true. I have tried really hard to find people ready to talk about DebConf, its issues, how to enhance it, etc... For a long period of time, I have not managed to find anyone to have that discussion. So "many people" is a bit exaggerated. I think we have had a really nice and productive discussion during Debian SunCamp. And I remember other attendees of the event that joined us (a bit later) and shared their thoughts on DebConf in general. > Later last year, a large number of long-time core DebConf organisers > asked you to find a way to remove from the team the person we all agreed > caused the most damage. > > After two months, you came up with a compromise that I found severely > insufficient. To this day, I can see that not even that compromise > solution was followed. > It was not a compromise (and still isn't). It is a first step solution. You may accept that complex situations require complex paths for resolution and take time. And this first step solution is still implemented as of today. We cannot reasonably expect anyone to resolve in a few weeks (or even months) issues of this complexity lasting for more than a couple of years. I said explicitly that a DPL is not the good person to talk to when it is about expulsion. That's DAM's territory. I can relay them the case but at some point, they will also need to talk to all involved parties in order to make a decision. And the decision is really theirs. If you want to ban someone from a mailing list, you may contact list-masters. If you want to ban someone from IRC, you may contact IRC operators. if you want to ben someone from the project, you may contact DAM. If you contact the DPL, then you're asking for some mediation. I have done a mediation and I did implement something that solves some issues in the short term. There is still a fair amount of work to do in order to fix the problem on the longer term. But, in such complex and long lasting situations, it is very important to work together. I do not expect anyone to reach any useful result while working alone on the matter. After all the energy and time I have invested on this matter, I have to admit that I found a bit rude to get a synchronized reply like "We did not expect this solution. Sorry, you failed". It was like a sentence and I did not have the right to respond. To this day, this is the first mail I get from you and you (and any other from the signees) did not want to work with me on the matter. I recognize my mail back then could have been better worded and I am really sorry for that. I can also imagine that the outcome was not the one you were looking for. But if we cannot discuss together calmly about this subject, I fear
Re: Q to the candidates: GPLv2 system library exception
On 30/03/2017 16:14, Ian Jackson wrote:
> Mehdi Dogguy writes ("Re: Q to the candidates: GPLv2 system library
> exception"):
>> On 29/03/2017 20:38, Florian Weimer wrote:
>>> Do you think this situation needs addressing? What do you propose do
>>> about it? Do you think the way the ZFS situation was resolved could
>>> be an example?
>>
>> I am not an expert in licensing issues but it is quite easy to ask advice
>> >from specialists on this matter and I'd approve spending necessary funds
>> to get qualified advice, of course. We already have an agreement with
>> Conservancy which allows us to ask them to work some limited amount of
>> time on a specific subject each month. We can start by doing that to
>> evaluate the complexity of the subject and discuss with them how we can
>> analyze this issue.
>>
>> (I'll contact you off-list to initiate that and see how we can work on
>> this subject)
>
> This seems like an excellent example of a thing that could usefully be
> delegated.
>
> Why not delegate someone who is interested, give them a budget cap,
> and ask them to:
> - consult within the project on the wording of the question to
> be asked
> - consult with SFLC, as authorised delegate of the DPL, to put
> and clarify the question and get the answer
I'd not necessarily bind it with SFLC though.
> - report back to the project as a whole
>
> I did roughly this for the PHP licence problem, without a DPL
> delegation, but simply with an explicit approval by the DPL for the
> laywers to talk to me. This process worked well until the report
> stage, where I felt I didn't have the authority to unilaterally
> publish the advice we had received and as a result it got sat on for a
> long time. A formal delegation with clear terms of reference would
> have solved this.
>
You are raising an excellent point. I think this is a great idea if
we have someone motivated to do this work. So far, we did not have
(m)?any requests for legal advices. Last one we have had was the one
for ZFS on Linux, which was in 2015. I have invited FTP team at the
beginning of my term to not hesitate to ask for legal advices when
questions arise. The process is actually quite simple: Last july, I
have asked DSA to create a private RT queue for such matters. We only
have to write down our request and have the DPL send a signed mail to
the queue. Then, Conservancy will receive a notification and can start
discussing with us the specific terms for the subject. Finally, if the
advice can be made public, it is obviously something we will share with
the community.
So, to get back to your initial questions:
- Yes, it is an excellent idea
- I did not push for this idea because of the low number of requests for
this type of "expense". So making up a budget (or a max sum) for this
activity can be done but it is not necessary right now.
- I'd very much encourage such initiatives if there are people motivated
to do the work
- To me, working on the fund-raising part and delegating the part that
takes care of approving budgets for sprints looks more useful (to me)
in the short term.
Regards,
--
Mehdi
Re: Q to both: facilitating meetups
On 30/03/2017 05:32, Scott Kitterman wrote: > In your platform from last year [1], you discussed this Roadmap (I > mistakenly recalled roadmaps, but you described it singularly). > > How is the Roadmap going? Is it defined? Where can I read about what's > been accomplished? Is helping Debian and if so, how? > I believe all the answers you are looking for are in: - https://lists.debian.org/debian-devel-announce/2016/12/msg1.html - https://lists.debian.org/debian-devel-announce/2017/03/msg4.html - and https://annex.debconf.org/debconf-share/debconf16/slides/51-bits-from-the-dpl.pdf for a more general presentation about why and how a roadmap can help Debian. To summarize, I've asked the Technical Committee to think about their contribution to the roadmap process and they did in https://bugs.debian.org/830344. Then, I tried to initiate a discussion with those who showed interest in the roadmap. Unfortunately, the discussion didn't happen. I didn't try to push for the idea harder as we are in a freeze and thought I should not distract people from fixing RC bugs. So my plan was to wait for Stretch's release and start a project-wide discussion on -project. Hope this answers your questions. > That's a slightly more verbose expression of the question. Does that help? > Yes. Thank you. > Scott K > > [1] https://www.debian.org/vote/2016/platforms/mehdi#roadmap > -- Mehdi
Re: Q to both candidates: preventing burnout by other contributors
On 29/03/2017 20:19, Chris Lamb wrote:
> Furthermore, putting people and teams together in real life is also
> another unexplored avenue. Whilst this speaks somewhat to my previous
> commitments for more meetups, the angle I am taking here is not waiting
> for the next {Mini,}DebConf or team summit but rather putting the two
> parties in the same room specifically to solve a social problem.
I was also thinking this was a good idea. Unfortunately, some situations
do not permit to put the two parties in the same room, which makes things
more complicated to handle. In such cases, one can try to mediate but it
requires significant efforts, time, real mediation skills and careful
wording. You can try to be very careful, and fail because your thought
was not described using the right words. It becomes even more complicated
when the victim in front of you is not able to accept any kind of small
error because in their perception, it might mean compromising with the
offender.
Dealing with such cases is really difficult. Even managers can have a
hard time with some employees because some offenders just do not care
about formal reprimands or having no raise. This is a question the humanity
did not resolve yet and we are not all competent in this area (especially for
persons coming from the IT world where we find it easier to interact with
computers... and even talk with our friends through computers and on
messaging systems where we do not even see their facial expressions).
I am really genuinely proud and really impressed with people behind Debian
Account Managers and Anti-Harassment team. They have been able to deal
with difficult situations and find the right words everytime. I can only
send them *hugs* for dealing with all that and show them the support they
deserve. I think we are really lucky in Debian to have those people. Not
all projects (or even companies!) have the same.
--
Mehdi
Re: Q to the candidates: GPLv2 system library exception
On 29/03/2017 20:38, Florian Weimer wrote: > > Do you think this situation needs addressing? What do you propose do > about it? Do you think the way the ZFS situation was resolved could > be an example? > I am not an expert in licensing issues but it is quite easy to ask advice from specialists on this matter and I'd approve spending necessary funds to get qualified advice, of course. We already have an agreement with Conservancy which allows us to ask them to work some limited amount of time on a specific subject each month. We can start by doing that to evaluate the complexity of the subject and discuss with them how we can analyze this issue. (I'll contact you off-list to initiate that and see how we can work on this subject) -- Mehdi
Re: Q to Mehdi: safe and fun
On 25/03/2017 13:52, martin f krafft wrote: > Dear Mehdi, > > among your priorities for your next term, should you get elected, is > "Ensuring the community remains safe and fun". Yet, I cannot find > much about that in your platform. > > Could you elaborate how you're intending to ensure a safe and fun > community? > Last year, I had to find new volunteers for the Anti-Harrassment team. Since then, I pinged the team regularly (by mail or by discussing over IRC with some of its members) to make sure someone is dealing with mails. I also tried to encourage press, anti-harassment and DAM teams to work together whenever an issue comes up. I believe they should work tightly together because they can have complementary roles in the same problem and synchronization between them is quite important. We have discussed with A.H. team about the idea of making a short report about current issues and how the team dealt with them. This could be a way to: a) inform project members regularly that they are active and working on issues raised by individuals; b) be transparent about issues Debian's community might be facing. Of course, the report would only mention the nature of the problems and solutions brought by the team. It must not disclose private information. Unfortunately, we did not make much progress on this report, but I am convinced this is something we need. And I really want to make this happen. About Code of Conduct, I think it can be enhanced in two simple ways: 1) make consequences of misbehavior more explicit. We are really not only talking about banning members from mailing-lists, but persistent offenders can be truly banned from the project. 2) List contacts directly in the code of conduct and do not link to the organization page. The information about whom to contact in case of issues should be easy to find and we should force readers to go through a long list of teams. The fun side is related to safety. People gather often to work together. We should encourage them to meet and socialize. Encouraging more meetups is a way. We should ask every team to try to organize a sprint. Make it regular. In order to keep such events safe, we must remind attendees about the values that are important to our community (which are well described in our CoC and our diversity statement) and tell them which team to contact in case of problems. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to both: facilitating meetups
Hi Scott, On 29/03/2017 13:34, Scott Kitterman wrote: > On Wednesday, March 29, 2017 11:25:29 AM Mehdi Dogguy wrote: > ... >> I believe the Roadmap will help us for the first subject and the partners >> program, once in place, will bring new (useful) workflows on the >> organization side. > ... > > IIRC, last year your campaign included this idea of roadmaps. Do you have > examples from your first year of roadmaps in use or being developed? > I am not sure I understood your question. Can you please rephrase it? -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to Mehdi: S.M.A.R.T. metrics
Dear martin, On 25/03/2017 13:42, martin f krafft wrote: > Dear Mehdi, > > in personal discussions and in your platform(s), you've been very > fond of the "S.M.A.R.T. way" aka. management by objectives. > I do not remember myself talking about S.M.A.R.T criteria in personal discussions to be honest :-) or if it ever happened, maybe it was because it was mentioned in my platform and elsewhere. In fact, S.M.A.R.T was used for Release Goals [1] and it has been also mentioned by previous DPLs as well (although, I failed to find a reference for that, for now). [1] https://wiki.debian.org/ReleaseGoals/ But anyways... I am not particularly fond of S.M.A.R.T criteria but I do recognize their value when it comes to defining goals and finding ways to measure their progress. It is good a tool that helps us to evaluate a goal by forcing us to think about five specific and simple points. > Can you identify a few objectives you've seen through in your last > term, and specifically illustrate how you measured progress? What > about projects still on-going? > In general, I have followed the same methodology for all subjects I've worked on during my DPL term: I have installed a kanboard [2] instance on my server ; created a project (let's call it DPL) and created tasks for every subject. Depending on the nature of subject, I added sub-tasks sometimes. Comments were also used to track the progress of the task. [2] https://kanboard.net/ -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to both candidates: universality
On 25/03/2017 13:04, martin f krafft wrote: > - What does universality mean to you and the project? > To me, in short, it means that we are able to address a wide range of different needs in a single homogeneous system. Debian has been successful as a general and stable platform where others can build on top of it to produce a more specialized product. The universality of Debian on the technical side has some consequences on how its community works and how it is built. Those different implemented needs were brought by people with different perspectives. Despite their differences, they were able to collaborate and work together in order to build a rich and unique operating system. I believe this aspect helped us to build a strong and diverse community over the years. But sometimes, some specific areas of Debian need special care. And due to the nature of our project, we are often unable to mobilize needed resources to make necessary changes. Universality may also bring some complexity. This leads us to situations where we can be stuck and are unable to embrace the change because it breaks old solutions (still useful to many). We eventually take the good decisions, but it takes a long time. At the same time, many contribute to Debian because it is fun. So if we are not careful, we may lose long-time contributors only because some change wasn't well understood (or well-explained, depending on which side you stand). Finally... while Debian contributors did a great job by integrating thousands of projects in one archive, I still think more efforts should be spent on making Debian easier to install, documentation easier to find, etc... I believe those points can help us to reach a higher level of universality. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q to candidates: reporting frequency
On 23/03/2017 21:20, Stefano Zacchiroli wrote: > Dear candidates, what do you think it's the appropriate frequency for > reporting back to the project about what the DPL is doing? > > Certainly, reporting often is time consuming and divert time from > actually *doing* stuff, rather than documenting what has been done. But > OTOH reporting seldomly ends up giving the impression that the DPL isn't > doing much except to those that, for whatever reason, end up interacting > (privately) with him/her. Where do you think is the sweet spot in this > spectrum? > I have tried to do monthly reports about my activity as DPL. It is not an easy task. Some subjects take a long time and it doesn't make sense (at least to me) to report about its micro-progress (because its status might be fragile or progress made is not significant enough). Some subjects are easy (or turn out to be easier than one could imagine) and are resolved quickly. My preference in the future would be to report about one subject on a monthly basis, and in the form of a blog post (e.g. on bits.d.o so that it is archived there). I believe this approach has two advantages: - reaching out to more readers than debian developers only (and few others subscribed to d-d-a) - more efficient communication (one subject, not diluted in a long text). -- Mehdi
Re: Q to both: facilitating meetups
On 25/03/2017 13:13, martin f krafft wrote: > Following the three-pronged approach Chris wants to take towards > facilitating meetups in Debian (I am replying to the message)¹ — > > ¹) <1489954668.1588748.916366632.0df7d...@webmail.messagingengine.com> > > I have three questions to both our candidates: > > In what ways do you see Debian itself being a bit of the rust on the > cogwheels making organization harder? > My answer might be quite general, but I think In my opinion, Debian is facing two problems: - Promotion: We do not explain enough how we do Debian, the important changes that Debian will implement, etc... - Organization: We want to encourage more sprints, provide hardware to developers, etc... but we can do that only partially because we still lack a clear vision on our budget. I believe the Roadmap will help us for the first subject and the partners program, once in place, will bring new (useful) workflows on the organization side. > Contrariwise, what do you think is already working really well? > It is quite easy to ask for a budget to organize a sprint. The procedures are quite light and simple. > What could be done from the side of the project to > improve/facilitate the organisation of meetups? > Once you have decided to organize a meetup, you have to find a location. I think it will greatly help the teams if we had a list of typical locations for sprints and possibly the cost of those locations (which can be offered by partners or with a fixed cost). Another aspect could be to work on a checklist for meetup organizers and some guidelines to have efficient meetings. We do have [1] but we can review it and possibly enhance it. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Question for DPL candidates: delegation
Hi Ian, On 21/03/2017 12:10, Ian Jackson wrote: > The DPL role is generally thought to be rather large and does seem to > be subject to burnout. But, the DPL can delegate whole areas of I do not think the DPL role is still subject to burnout. It certainly requires some commitment but it is in no case something that requires extraordinary powers or superhuman energy. At least, not anymore. > responsibility. At the moment DPL delegates are mostly longstanding > core teams such as ftpmaster and DAM. We have also had the > semi-formal "DPL helpers" but they didn't have delegated authority. > > Do you intend to make more use of delegation ? In what areas of DPL > responsibility ? Do you envisage delegating individual issues on an > ad-hoc basis, or whole areas to new or existing teams ? Do you > envisage sending out public calls for volunteers ? > I am all in favor of avoiding concentration of powers as I think it may cause harm to our project to solely focus powers and expectations on a single person. It is also even more important to avoid such situations when we know DPL terms last only for 1 year. Some subjects require stability and ability to plan for more than a year. So keeping the DPL as sole decision-make on such subjects is not a smart decision. As of now, DPL has been in charge of approving expenses. I am not convinced we should keep doing that in the long term. My idea would be to develop a few specific teams in charge of approving and dealing with specific kind of expenditures and another team to collect donations. I can imagine a team formed with representatives of the following teams: - DSA (hardware and hosting part and everything needed to run Debian's infrastructure like domain names and SSL certificates, if still necessary) - DebConf Committee (to specify DebConf needs) - Outreach team (for Debian's participation in outreach programs) - Partners team (for collecting donations for Debian) - Roadmap team (to request a budget for sprints related to the roadmap and possibly general sprints). Each team can be autonomous on its perimeter. The DPL could allocate shares (or specific budget lines) for each team. They will be delegated to handle expenses on their respective area of activity. A few times every year (e.g. 3 or 4), we can make a financial review. This will help us to produce more easily a financial report at the end of the year. So, in general, yes, I am in favor of making more delegations when contribution of the DPL is not required or not the best fit for the task. > Would you look favourably on unsolicited requests from a contributor, > to have limited powers delegated to them to deal with a matter that > contributor wants to try to see fixed ? > I am certainly in favor of enabling people to do more stuff, especially when their work benefits to the project at large. So I could delegate them temporarily (or not, depending on the task) with specific powers to make their subject move forward. But, motivation is not enough. They also have to show ability to work with the rest of the project w/o raising much concern from their fellow DDs and the delegation must not be covered by the work of another team/delegation/role. So I guess some situations would require mediation and discussion. Delegations can be powerful but they are not a magical tool to solve all problems. Regards, -- Mehdi
Re: Question for DPL candidates: Board of directors?
Hi Sylvestre, On 22/03/2017 21:30, Sylvestre Ledru wrote: > Hello, > > During your term, is there any chance that you work on replacing the DPL role > by a board of directors? > No. > If not, why? > Because I do not like jumping on conclusions. Let me explain further. I agree that it is becoming harder and harder to have DPL candidates. I agree that we must do something. That something cannot be directly "replacing the DPL role by a BoD" because: - First, we have to understand why we have this problem - Then, why this is a problem - Finally, we have to list what we do not like with the DPL role and we want to enhance. Based on that analysis, we can see how to improve the situation. If do not have a clear understanding of the situation, we are not going to improve it in any way by picking solutions that worked well in other projects. I think that Debian is quite unique in its governance and may require us to be more imaginative to find a suitable solution for the project. I have to admit that I wasn't worried last year when I was the single DPL candidate. I am worried this year because I think the situation didn't improve this year. It is true that we have two DPL candidates but there not many questions asked during the campaign period. So I was thinking of organizing at least two BoFs: - One specifically targeted on the DPL role: What the DPL does? What he should be doing? What to expect from the DPL? What is people's perception of the DPL role? - Then, based on the input of the first BoF, a second BoF about Debian's Governance where we could start thinking about solutions on how to improve the situation. There are many possible solutions (based on the issues that we are able to identify): 1) Evolve the DPL role to something that fits more nowadays project's needs; 2) Change DPL role with another role or another structure; 3) ... I am not sure we all have the same expectations about the DPL role nor we have a clear understanding about what other structures could bring us (that we are unable to achieve with the current DPL role). So all this should be discussed so that we collectively feel that we are able to identify the best solution for our project and list specific arguments against old situation and in favor of the new one. So you can count on me to organize those two sessions and make a summary of those two sessions (possible with an action plan). But I am not yet convinced that we have identified the best solution to improve the situation. I've always seen the DPL campaign as a way to push motivated DDs to identify ways to improve the project, push for new ideas, etc... and give them the ability to implement them. A DPL has a clear scope and powers (documented in our constitution) and can be helped by other contributors whenever he feels it is necessary. Some innovation in our project comes from DPL campaign where we have to put things into perspective and plan for the future. I am personally attached to those aspects. Regards, -- Mehdi
Re: Questions for Mehdi: roadmap?
Hi Steve, On 18/03/2017 23:02, Steve McIntyre wrote: > Hi Mehdi, > > First of all, thanks for standing again! > > Do you have any specific things that you'd like to see on a Debian > roadmap yourself? > I have some specific ideas. I didn't want to share them (although already mentioned elsewhere by other DDs) but I understand the need to read some examples to better understand the spirit of the roadmap. - deprecate source format 1.0 (though this one will require a project-wide discussion and a concensus). - debci as a testing migration blocker - “Essential:yes” and “Required” packages are reproducible or even better "Every stable release is 100% reproducible" (and becomes a release criteria). - All packages with daemons provide a unit file for SystemD - Move from menu system to .desktop files - Secure Boot Depending on our investment for each goal, we may be able to implement them in time for Buster. > Assuming that roadmap ideas are forthcoming, how do we ensure that > teams responsible for the various areas have the will and effort to > follow through? We are not going to fix manpower, motivation and commitment issues with the roadmap. But, I believe that it is fairly reasonable to expect: - More people paying attention to important changes going on in the project and important goals set by contributors. This means that we could potentially have more contributors for each goal. More people working on a goal also increases motivation. - Promoting our work and encouraging participation in conferences around those goals is rewarding. - Communicating about our roadmap and its progress is putting more light on all those little projects that make Debian better after each release. - Encouraging at least one sprint per year for each goal increases productivity. You may argue that we already do that today w/o a roadmap and I would agree. But it is really much easier to approach contributors when you know on which specific "change" they are working on. The sole type of event we organize where we encourage collective work is Bug Squashing Party. We can imagine collective sprints on a roadmap goal. A taskforce that has in mind a shared goal for two days. I tend to believe that a mix of those 4 points will have a positive effect on people's motivation and commitment. We also tend to focus on packaging tasks too much (in my opinion). One goal behind the roadmap is to show that packaging is only a tool that helps us to reacher a higher goal of making the best operating system and enriching the FOSS ecosystem (thanks to our incremental contributions to every packaged projects). It opens new ways to contribute in Debian. -- Mehdi
Re: Q to Mehdi: partners program
Hi Lucas, On 16/03/2017 12:15, Lucas Nussbaum wrote: > Hi Mehdi, > > In you platform, you mention the partners program, and apparently a lot > of progress was made recently. This was a (good) surprise for me. You > write: >> With the help of the new partners team I formed during my first term, >> we started to make a list of current partners and sponsors. We are >> working on the new program and I hope we will be able to make its >> first version public in time so that it can be beneficial to >> DebConf17. With that in place, we will be able to discuss with >> potential partners the terms of their support. > > I must admit that I just discovered > https://www.debian.org/partners/2017/partners.en.html > > Was this announced somewhere, and did I miss it? Or was it not announced > yet? > It has not been announced yet. Please bare in mind that this is still work in progress and not official yet. > Are the members those listed on > https://www.debian.org/intro/organization.en.html > (was the call for help public?) > Both Luca and Laura expressed interest in the partners program. I have discussed about this subject with Luca during DebConf16 and with Laura over IRC. And then, we started iterating on different points to shape the program. > Was there a (recent) public discussion about that program? > Not yet. I am fairly convinced that discussions are more effective when we have a proposal at hand to criticize and not completely open. The proposal will be sent out publicly for discussion as soon as it is ready. -- Mehdi
Re: Debian Project Leader Elections 2017: Call for nominations
Hi, I hereby nominate myself as a candidate for the 2017 DPL election. -- Mehdi Dogguy signature.asc Description: OpenPGP digital signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On 08/07/2016 15:27, Margarita Manterola wrote: > > === BEGIN GR TEXT === > > Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > > All appearances of the word Chairman shall be replaced with the word Chair. > > === END GR TEXT === > Seconded. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
Hi, On 07/07/2016 15:37, Nicolas Dandrimont wrote: > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === > Thank you Nicolas for working on this and bringing it up! And… seconded. -- Mehdi signature.asc Description: OpenPGP digital signature
Re: Q: DPL job profile?
Hi, On 24/03/2016 12:55, Lucas Nussbaum wrote: > Hi Mehdi, > > Last year, Ana started a great thread about the role of the DPL[1]. > > I wonder where you stand wrt the various positions in that thread? > What will be your priorities when deciding what to work on? > What do you see as tasks that the DPL must do, should do, may do, > shouldn't do, mustn't do? > I pretty much agree with what you wrote in [0]. Contrary to what has been said in that thread, I do not think the constitution should be more specific about DPL tasks. A DPL is defacto a garbage collector, as formally written in the constitution (§5.1.4). Being open about what a DPL can do allows one to innovate and start new things. It is quite difficult to say which tasks should come first when you never did the job before. I imagine tasks with a deadline should be made a priority. Anything that may be blocking the project (or some parts of it) should be on top of the TODO list. In any case, I intend to be quite transparent on my time spent as DPL (if elected) so that folks may have a better understanding of the DPL job. Communication is the crucial bit in this story. Looking at Ana's list of DPL tasks in [1], I have a few remarks: - I do not think the DPL should set technical goals for the project. He should certainly help to make sure goals are set and a consensus is reached though. - My understanding is that dealing with technical problems is the area of action of the Technical Committee. Of course, a DPL can participate during the discussion and may help to resolve the problem… if it is required. Not all technical problems require that though. - Other people may represent the Debian project and give talks on behalf of Debian, not only the DPL (as I've said in [2]). [0] <20150214090708.ga12...@xanadu.blop.info> [1] https://lists.debian.org/debian-project/2015/02/msg00039.html [2] https://www.debian.org/vote/2016/platforms/mehdi#approach -- Mehdi
Re: Broader vision
Hello Enrico, On 21/03/2016 16:29, Enrico Zini wrote: > Hello Mehdi, > > in your platform there is a section "Vision" that deals with several > important practical aspects of Debian. > > I see the DPL as a person that we choose for a year to give the project > a broad sense of direction, to inspire, to keep people's perception of > Debian up to date, to tell tales of what Debian has become, to tell > tales of the wonders that are about to come. > Note that later you reduced this list simply to: "to inspire". I do not think it is a good summary, but I'll keep this in mind when writing my reply below and will consider "to inspire" below to be the contraction of the above list. > As a thought experiment, suppose that you managed to delegate all the > everyday tasks of approving expenditures, facilitating practical > decisions, even answering regular lea...@debian.org email, to good and > skillful people you can trust. > Wonderful. :-) Is that also valid for social and/or organizational issues? I believe they take a fair amount of DPL time. > You are then left with the one thing that you cannot really delegate: to > inspire. You are on the biggest stage in the project. Everything you are > going to say will instantly appear on LWN and at the top of Hacker News, > you are going to give keynotes in the most important conferences around > the world, participate in strategic meetings where the future of IT is > discussed, to see if and how Debian wants to be in it. > > How do you see Debian right now? > > How do you imagine Debian to be in one year, when you will be > summarizing the recent history in your campaign for re-election? > > How do you imagine Debian to be in the distant future of IT, say, three > years from now? > FWIW, there was a similar question last year (See [0]). This mail intends to be also a reply to <20160322073627.ga24...@xanadu.blop.info>. Debian is inevitably one of the biggest and most successful FOSS projects. It has a remarkable longevity and is still very widely used. All of that is built by a solid (evolving) community. Our success is often linked to the stability of our releases, our free software philosophy, and our attachment to technical excellence. Some tools have contributed to our success, like our holly famous package manager and our modular installer. All of that is challenged every year and we should embrace change in order to keep our project relevant. The Linux distribution model became less relevant with time. It doesn't mean that we have to stop doing what we do best, but some things need adjustment. We lack a roadmap. Many things are done within the project, but not properly advertised. Our new stuff and priorities are not properly communicated. We used to have a list of release goals which served, somehow, that purpose but the Release Team decided, rightfully, that it is not their job to set technical goals for the project. Now, we have to resume that effort and publish a roadmap that will be useful to our users and upstreams. Contrary to our historical Release Goals, a roadmap doesn't have to be bound to a release, but should give some idea about when each item will be implemented and where the project is going. People may even find it interesting and decide to contribute to Debian. But in any case, i believe this will greatly help our ecosystem (users, upstreams, downstreams, other fellow f/oss actors, etc…) to better understand our vision and priorities. Software projects are releasing often nowadays. This make it difficult for us to integrate a useful version and maintain it through stable's lifetime. Our release strategy allows us to release highly stable versions. Our tools make it possible to customize almost every aspect of Debian. This strategy fits perfectly for the base system and a perfect solution for anyone building a derivative. Other uses are left behind because there is no match. We started making compromises once we noticed that security support is not achievable for some important packages (web browser, database server, ...). So our release policy is evolving but rules are not clear yet. I think that something can be done in that area. Project members expressed the urge to have some equivalent to PPAs. While I sympathize with the idea, I wonder sometimes what would be the goal. Developers personal archives turning into a way to release to users might be one of our new nightmares. What we do best is to integrate various projects together and ship a coherent tested whole. If we start releasing separately, the concept of "distribution" will vanish. In my opinion, we are looking for ways to release faster. A PPA is one solution. I don't think it is the best solution for that problem. A better idea, IMHO, is to think about a new release strategy. Packages in a Debian stable release should not all evolve at the same speed. We are already making exceptions for some. We should work on a set or rules that would make it possible to update
Re: Lars Wirzenius' not-platform?
Hi, On 18/03/2016 00:40, Paul Wise wrote: > To the candidate: > > Have you read Lars Wirzenius' not-platform? > > http://blog.liw.fi/posts/dpl-2016-not-platform/ > > Do you have any thoughts on it? > > Does Debian need the Social Committee proposed by Lars? > The candidate replied in <56ed3f23.4050...@dogguy.org>. :-) Feel free to follow-up there. Regards, -- Mehdi
Re: encouraging events?
Hi Daniel, On 17/03/2016 11:58, Daniel Pocock wrote: > > Hi Mehdi, > > I've been reading over your platform, I couldn't help noticing it is in > all seriousness better than some of the other candidate's running for > high office right now. The only other thing needed to be in that league > of course is fostering good relations with Irish voters[1] > Thanks. I'll make sure this is taken into account next time. :-) > If Irish developers were to try and organize a MiniDebConf for the > weekend of 18-19 March 2017, would you be happy to support that as DPL > and provide some funding if necessary to make it happen? > A mini-DebConf is a mini-DebConf. I don't see any specific reason not to encourage it. The procedure to get it funded is documented in [1]. [1] https://wiki.debian.org/Sprints/HowTo Regards, -- Mehdi
Re: thoughts on liw's non-platform?
Hi Paul, On 14/03/2016 04:25, Paul Wise wrote: > Hi Mehdi, > > Lars Wirzenius recently wrote a blog post entitled "Not-platform for > Debian project leader elections 2016". I wonder if you have any > thoughts on what he has written there: > > http://blog.liw.fi/posts/dpl-2016-not-platform/ > liw's platform is devided into two parts. First part shows describes opinion about DPL's role. Then, another part follows about the idea of the "social committee". I mostly share what he wrote about the role of the DPL. It describes in a few items where a DPL can be expected to act. There might be a little mix between people's expectations and real priorities of a DPL though. Inspiring and motivating people is, at least IMHO, a little different from making things run smoothly. Indeed, DPL's primary focus should be to make sure there are no big blockers, and that people are able to get things done (in a satisfactory way by Debian standards). Inspiring and motivating people should be everyone's job! It is not something that a DPL should do specifically. It might be a way to make things run smoothly, but it is not a goal per se. Motivating people day after day can be done simply by trying to be helpful, replying in a respectful way, being welcoming, etc… Inspiring people is a much harder job, and people should not wait to become a DPL in order to try! As I said in my platform, innovation is expected from every project member. Inspiration is no different. The second idea of the platform is about the fact that the DPL is overwhelmed by social conflicts and spends a lot of time trying to resolve them. liw explains that a dedicated committee might help by taking this burden off the shoulders of the DPL. I acknowledge the issue and I sympathize with the idea but I am not sure how it could be applied in real life. Conflicts can hardly be characterized. Mediation is not an easy task and requires (IMHO) some creativity and patience. I don't think that finding a committee that will be suitable for all sorts of conflicts is realistic. If a problem escalated to the DPL, then I see (at least) 3 main situations: 1) The requester doesn't know who to ask to resolve the issue; 2) Involved people need a new opinion on the matter; 3) The issue got worse and nobody is able to speak to each other. First, I expect the DPL to understand the nature of the conflict and identify involved parties. I don't expect the DPL to do miracles in conflicts like #3 above. Then, a DPL may try to resolve the conflict by himself or delegate, when possible. This is all theory though. I don't have an accurate idea of the amount of conflicts where a DPL is asked for help. I don't imagine the number to be huge, but I expect subject to be lengthy and require a large amount of time until resolution (in best case). We don't know who would be motivated enough to help when issues occur. Maybe that's the purpose of the proposed committee. But I don't see what kind of special authority it could have (anyone is free to send mails and talk to people). It'd help to have a list of people available and ready to help resolving conflicts, if ever asked to. That surely will ease the DPL's job to some degree. Whether the list is a committee or not doesn't seem relevant. As the committee is described in liw's non-platform, I am tempted to say that our social committee is all project members. It should not be bound to one entity. Regards, -- Mehdi
Re: quantity of DPL candidates?
Hi Paul, On 14/03/2016 03:53, Paul Wise wrote: > Hi Mehdi, > > Any thoughts on the low amount of DPL candidates this year? The only > year we have had a sole candidate was when zack ran for second-term > re-election in 2011, which is a quite different situation to this > one, where the previous DPL is not running for re-election. > TBH, I don't think the situation is new. We've always been tangent and never had many candidates (except a few times). I agree that the situation may be surprising (and I was also surprised no one else was standing up), but I don't think there is any conclusion to draw except maybe that people realize the difficulty of the DPL job and don't take it lightly. Instead, I think we have to find new ways to encourage people to (at least) consider nominating themselves next time. We could imagine for example IRC Q sessions to better explain the job and what it takes to do it. Then, we have to think about how to effectively off-load the DPL, but it requires categorizing activities and estimating % of time spent for each one. > How do you think this situation reflects on the health of the Debian > project? > I would not generalize this as a symptom of an unhealthy situation of Debian. The DPL job is not an easy one. We cannot blame people for not nominating themselves. > Do you think we should vote for NOTA until someone else nominates > themselves? > If you meant to collectively vote for NOTA, then I think that this is the best solution to make the situation even worse. IMHO, standing up for a DPL election requires preparation and serious thinking. You don't usually decide within the nomination week, but start preparing it a while before. I am not convinced that waiting for another week will help us to magically find another candidate. If people didn't want to nominate themselves for DPL, then we should not force them to do so. Having "fake" candidates is not doing the project any favor. No one wants an inactive DPL. No one wants a DPL that is unprepared for the job. Last but not least, why would we be requiring a minimum of two candidates? Fake competition is not sane. And I don't think my candidacy would be more serious if we were two candidates. In fact, last year's votes showed that my candidacy was serious enough to have the highest majority. I don't think that your choice last year was motivated by the number of candidates. So, we can also look at this situation from the brighter side: What if voters think we have a good enough candidate and decided to give him his chance? This could also be interpreted as a maturity sign from project members. Indeed, the goal is not to have an exciting campaign with many candidates, but only to choose someone fit for the job. Of course, if project members think otherwise and don't think I am fit for the job, they are free to individually vote for NOTA. Regards, -- Mehdi
Re: Debian Project Leader Elections 2016: Call for nominations
Hi, I hereby nominate myself as a candidate for the 2016 DPL election. -- Mehdi Dogguy signature.asc Description: PGP signature
Re: More women in key positions ?
Le 31 mars 2015 02:49, bjf...@gmail.com a écrit : After explaining we have an impressive ratio of female to male participants in the Debian project as a whole (not just technical), your suggestion is to get more women involved generally with Debian (still not technically)? No. At all. It would be great to have more female contributors involved, and it would be even nicer to have them contributing on technical aspects of the project. Did I miss something, it seems if anything it would make more sense to say we need more women in CS/IT generally after your first claim... Of course, it would make a lot of sense to tackle the question from a larger angle... to have more women in CS/IT generally. But what can specifically the Debian project can do about that? I beleive that encouraging more women to contribute to Debian could help in that regard. But i am not sure of what we can do on a more general level. -- Mehdi
Re: Q to all candidates: dropping SC §5
On Sun, Mar 29, 2015 at 02:37:12PM +0200, Stefano Zacchiroli z...@debian.org wrote: - I don't think the analogy with debian-multimedia is pertinent. At all. The problem with debian-multimedia.org was that the agenda of the people behind that 3rd party repository was completely unaligned (if not even conflicting, at times) with the agenda of the corresponding Debian team under debian.org. Things would be completely different if people behind debian.org and (hypothetically) non-free.org were to work in concert, with an agreement of what belongs there. You seem to be a real fan of the tautology club ;) as you say (after major rephrasing): If the situation is okay, then it will be okay. I don't see any guarantee to have people behind debian.org and (hypothetically) some-another-non-free.org work in concert. If it doesn't happen, then we will face similar issues as the ones we faced with debian-multimedia. This is part of our history now and we can surely learn from past experiences to be able to handle similar situations better in the future. But there is still some risk to see such initiative go out of our control if their agenda doesn't match ours. I agree that it is an hypothetical situation, but so is yours. So I don't agree on the fact the analogy is not pertinent here. It really does, but it is important to keep that in mind to not be trapped once again. Regards, -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150331215320.ga21...@dogguy.org
Re: Q to all candidates: dropping SC §5
On Wed, Apr 01, 2015 at 12:07:07AM +0200, Stefano Zacchiroli z...@debian.org wrote: On Tue, Mar 31, 2015 at 11:53:20PM +0200, Mehdi Dogguy wrote: This is part of our history now and we can surely learn from past experiences to be able to handle similar situations better in the future. So, you got me curious: what do you think could have been handled better in the debian-multimedia case? - Further discussion with people behind $some project - Broader communication from the project that $some project is not affiliated to Debian and doesn't share our goals/ideas/etc... This includes but not limited to: * Wiki Page * d-d-a mail * Dent/twitter (not back then, sure :) * mention in the release notes * mails in various user communities - Get them not to use debian in the name of their project - Get tech-ctte involved, if all parties are Debian members. though not all of the above points could have been tried 10 years ago but those can be used in the future, if needed. But as I said, it was a learning experience and we should keep it in mind to avoid in the future. -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150331230524.gb21...@dogguy.org
Re: Q to all candidates: dropping SC §5
Hi, Le 2015-03-26 20:21, Bas Wijnen a écrit : So to the candidates: can you please let us know whether you would be in favor of restricting non-free, so that it will only contain things that are required for making hardware work, and for which there is no fully functional free alternative? If not, do you think restricting it on other grounds is a good idea? If so, which criteria would you suggest? As underlined by algernon, there is also some useful documentation in non-free. If you have a look at non-free's content, you will notice that there not many packages (~0,01% compared to main's size). I don't expect this to change in a near future because the community is also not so interested in non-free stuff and generally seeks free alternatives. The list of packaged non-free projects from _ten_ years ago counts (approx.) a hundred less packages. ~60 of them are for mbrola (a multilingual software speech synthesizer) and mgltools (Molecular Graphics Laboratory). So not only their number is ridiculous, but given their variety, it doesn't seem easy at all to give an criteria. I think that naturally we are leaning towards keeping only firmware and software for which we don't have a good free alternative yet... which doesn't seem all bad. So, restricting non-free to hardware stuff doesn't seem necessary. It would also require a lot of efforts, but for no much gain (IMHO). The consequence of doing so might be the creation of some debian-nonfree.com which will deliver today's non-free content, with possibly more non-free software. This will make the situation even worse. Does this remind you of some story? Yes, debian-multimedia and we've seen the bad consequences of such initiatives. Not entirely related but, we've also seen cases of software moving from non-free to main. In many cases, upstream was convinced that their license doesn't bring any good or that the restrictions put in place are not effective. A better proposal would be to create sub-suites in non-free as explained in #781365. I wouldn't create many sub-categories though as this would not be stable over time. I'd suggest creating only needed ones, where needed needs to be defined. Before doing so, we should reach on consensus over what to enable and how from the installer. This is also related to Paul's point: On Tue, Mar 17, 2015 at 02:16:09PM +0800, Paul Wise wrote: Add an extra component that d-i could add to sources.list when non-free firmware is needed, instead of adding all of non-free. Likewise for drivers, GNU documentation, the web, tools for external APIs and other common categories of non-free things. (Aside: I like all the ideas in Paul's mail, but this one is relevant here.) Would you be in favor of such categories of non-free, where we can perhaps include some of them (firmware) by default on installation media? Depends on what do you mean by by default :-) I don't want a non-free repository to be added without an explicit approval by the user, and after been explained the consequences. -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/63563ee00ec2369e3b4edb22912e8...@dogguy.org
Re: More women in key positions ?
Hi, Le 2015-03-21 03:50, Charles Plessy a écrit : You probably noted that no woman was candidate this year, and that no woman was appointed to the technical committee in the recent replacements. Do you think that it is a problem that there are no women in key positions in Debian ? If yes, what do you plan to ameliorate the situation as a DPL ? I think that the question is much more large than that. I'd like to point out the fact that we already do have some women in key positions, and with highly important role (Front Desk, DebConf chair, Publicity team, ...). We may have technical subjects in mind but Debian is a big project and there are other non-technical aspects. The number of women we have in key positions is even remarkable when we take the ratio of active women in the project. IMHO, the question is rather why we don't have more women involved in Debian? ... and there are many factors. There are social and cultural factors about which Debian can't do much. For the rest, it is not new that there are very few women in the free software community. Initiatives like Outreachy (or rather OPW) showed great results and we expect the same in our community. We introduced the Code of Conduct and the Diversity statement. Both make Debian a more welcoming project. We should also take great care of keeping women who are participating. -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/08866c301eb1e170d8b56cc3aa583...@dogguy.org
Re: Q to all candidates: Debian in five years?
Le 2015-03-14 21:59, Lucas Nussbaum a écrit : There has been some discussions about the focus moving to other areas of Free Software, distributions being solved problems, containers as a alternative/better way to ship software, etc. In five years, what should Debian's position and role be in the Free Software ecosystem? Are there other positions where we somehow risk ending up? What can we rely on to get to that ideal position/role? What are the main things we should worry about (including, but not limited to recent trends in the Free Software world)? IMHO, Debian's contribution in the Free Software ecosystem is twofold: - We make the largest and one of the most used Linux (and sometimes other kernels) distribution. - We care about our users and software freedom. We make a lot of efforts to make the distinction clear and bold between the two worlds (free/open and non-free). I don't expect those two points to change anytime soon. But every year, those two points are challenged, and we work hard to keep them current. As outlined in the SWOT analysis, we have the opportunity to tackle new subjects or put more efforts into those subjects. Those subjects include (but are not limited to): cloud services, containers, complexity of software stacks, security, privacy. Each one of them is challenging and puts our position back into play. On the technical level, I do not expect our role to change but a lot of changes will happen in the way we play that role. We have a strong community but we have to keep recruiting new skilled people as software become more and more complex and us facing new challenges. Well, we talk so much about on-boarding new people but we may forget the awesome people that build Debian today. We should keep those too... They may be useful :-P On a social level, we see more people concerned by the diversity in our communities (and other free software communities in a more general way). Debian played a role there since years and I expect us to continue doing so and even more by caring about other minorities. We will also continue to play an educational role to re-explain what is the free software philosophy and why it is relevant today (more than ever). -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54ad82e08e834f58698d20a5b492d...@dogguy.org
Re: Q to all candidates: DebConf orga
Le 2015-03-13 12:03, martin f krafft a écrit : What is your perception of DebConf and its organisation? If any, what changes would you like to implement? First, I'd be careful here because we have DebConf chairs which are official delegates. So, I'd leave them implement whatever changes are required. At best, I'd make some proposals but I don't think it would be nice to start by implementing changes there. I've attended a few DebConfs and was always very impressed by the work and organization. There a lot of people involved (locally or remotely) and they have enabled Debian contributors to meet during one or two week for the project. So I am grateful to all these people for past and future editions of DebConf. As many things we do in Debian, DebConf's organisation is quite complex. But unlike Debian releases, DebConf doesn't happen when it is ready. There are dates sets and a hundreds of people coming to the conference. (and more and more, babies involved :p). The pressure has to be high on the shoulders of DebConf volunteers and failure is not an option for them. Fortunately, people involved in the local team of past editions get themselves involved in next editions. So there is some experience that gets passed on from a year to another. Organizers of future editions are invited to participate in current organisation and attend meetings so that they get used to the process and workflow. So, all this dynamic is positive to make DebConf a success. But some questions pop up every year about fundraising and accommodation. Fundraising has always been a huge amount of work and there have been some uncertainties about its feasibility for almost each conference. Sponsorship for attendees was also subject to many questions since, for example, it really depends on how you sell yourself when you ask to be sponsored. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20d35579d5b2c91c31bd3d5a60811...@dogguy.org
Re: Thoughts/questions for any candidate
Hi, Le 2015-03-13 02:20, Anthony Towns a écrit : Number one is something like where should the innovation come from? GN You may notice that unlike in previous years, I do not have a Grand GN Vision, not in the same sense at least. MD Of course, those are not trivial questions and I don't claim I have MD answers. Solutions and ideas will come from contributors. Solutions MD will come from you! Do not be shy and do make proposals. I think it's fair to say algernon and mehdi both emphasise the role of supporting other people's innovative ideas rather than promoting their own. (Maulkin splits the difference a bit, I think, given he's got a specific proposal for PPAs and buildds in his platform) That's a very workable plan, but it has one (IMO) huge drawback: the DPL position is /the/ optimal place to be in Debian if you want to be innovative. You have resources, your ideas have been scrutinised and (to some extent) approved by the developers, and (almost) whenever you want it you've got the immediate attention of developers, users, the press, or sponsors at your beck and call. The DPL position is ideal place to get attention, but not necessarily to be innovative, /If/ the DPL is innovative, it is good... but I don't see the link between visibility and innovation. Given the DPL's activities, his cool new stuff will likely not be a technical project but of other nature. Is it fair to expect cool new innovations within Debian if all the attention goes to someone who's not doing cool new stuff? TBH, I found your remark a little bit unfair: algernon's platform and approach to the DPL role is, what we can describe of, innovative. So I expect him to be innovative even he didn't list explicitly innovative plans. In my platform, I outlined a few projects I worked on which I consider innovative too. We don't necessarily realize it easily but we are part of a nice community where innovation is widespread. The main problem that I see is that innovation might not be visible to everyone and that's where I expect the DPL to take advantage of his position and advertize new cool stuff happening in Debian. Number two is something in that nature of how to share the DPL's workload. I think this is widely acknowledged as a challenge, eg: NM the job of the DPL is a tough one that requires a lot of work, and NM I don't want to bite off more than I can chew MD The DPL role is very time-consuming. To be able to do it seriously, MD I will put on hold my other Debian activities for the duration of MD the mandate. I have three thoughts on that. First is that (I believe) one of the biggest workloads for the DPL is conflict resolution/mediation. But there's recently been some talk about the tech ctte addressing that same issue eg [1], [2]. It's obviously an open question whether it will work or not, but I'd be interested to know if the DPL candidates are thinking of trying to help make it work, and (if/when it does) to refer folks to the ctte freeing up DPL-time for other things? Freeing up DPL-time by making other people more busy doesn't scale well, IMHO. It is also more problematic if that group of people is busy enough already (and even if awesome people joined the team recently). Sometimes, people should remind themselves that there is another human on the other side of the line. Many remember this when they meet other people in real life. They start thinking twice before sending an email. Maybe we should encourage people to get talk to each other and hear each other's voice. We used to do that in Debian's early days to confirm new contributors' identity. The second idea on this I have is perhaps a little twisty. First a reference from a while ago: [3]. There have been lots of ideas on how to scale the DPL role -- teams, 2ICs, boards, helpers, etc. Problem is, none of them have worked perfectly, and everyone who's elected DPL is a leader, not a follower, so they come up with their own plan from scratch. Then that idea doesn't work perfectly either, rinse, repeat. At some point, we need a DPL who'll take one of the previous ideas that worked a little, improve it only slightly (ie, so it's still recognisable), and turn it into a tradition that can keep improving. Any chance of that happening this year? It is true that I didn't mention explicitly in my platform how I'd share my DPL-work, if elected. As a DD, I can only observe that previous plans to share the DPL's workload didn't work perfectly. But I still think it is important to keep trying for many reasons. One of them is simply to make sure others understand the DPL's activity. The second reason is related to the fact that I don't expect the DPL to do all what he has to do alone. So, it is reasonable to off-load some tasks to other groups or individuals. As mentioned by Neil, #debian-dpl was a nice initiative and I'd be happy to keep it going as it has been useful for both DPL and helpers... and is open to everyone.
Re: Q to all DPL candidate: PPA
Le 2015-03-17 01:19, Thomas Goirand a écrit : On 03/15/2015 09:57 AM, martin f krafft wrote: Neil, in your platform, you advocate PPAs and modernising our build and infrastructure. What's the DPL's role in this? Or, put differently, couldn't you just start working on this without the DPL hat? Why not? What's the difference here? Well, actually... To all: what do you think you can do to make the PPA thing happen? For this kind of subjects, it is important to really understand what is missing to make it happen. From what I gathered, it is a mix of lack of manpower and technical issues. A DPL can do little about technical issues, but can try to make a call for help if involved teams are okay with that. It could help to get the problem more visible and attract new people. A DPL can also encourage a multi-team sprint so that people are gathered and can at least work out a plan. We were also discussing how to onboard new contributors. I believe PPAs could do a perfect subject for an internship as it helps the applicant to better understand Debian's internals and meet several teams. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f1aab0d5f516e1acd8fbc732f8ff2...@dogguy.org
Re: Q to all candidates: spending money
Le 2015-03-17 10:03, martin f krafft a écrit : also sprach Mehdi Dogguy me...@dogguy.org [2015-03-17 09:56 +0100]: For a start, Debian can fund two slots *this* year. If we want to do this sustainably, we will have to make sure we have funds dedicated for it Just funding the slots won't cut it, at least not if we want a return. Outreachy, and all other ways and aspects of recruiting need active management. At the moment, a few people are working hard to keep up, but to build a team, we'd need to give it a perspective, don't you think? Why not proceeding step by step instead of trying to build up big plans even before we start? -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f0730e49c213c2b4de7d909079fe3...@dogguy.org
Re: Q to all candidates: dropping SC §5
Hi, Le 2015-03-16 08:59, Stefano Zacchiroli a écrit : On Mon, Mar 16, 2015 at 09:31:03AM +0100, Gergely Nagy wrote: So, the only way I could see the drop of SC §5 as a worthwhile goal, is if we also removed non-free (and possibly contrib) too. I respect this point of view, even though I disagree with it: I think it is desirable to drop SC §5, without (at least at the same time) dropping contrib/non-free from our infrastructure. Can you elaborate on why dropping §5 is desirable for us? As currently worded, Debian acknowledges the existence of this area and even says that it doesn't meet our free software standards. It also explains that packages from the non-free or contrib areas are not part of the Debian system. I can understand that some people or organizations are not happy with the fact that we provide non-free software integrated into Debian... but is hiding it in a (documented) repository area will make things better? As explained elsewhere, this enables some of ours users [1] to use our system based on free software and a little part that is non-free. Which is a good compromise, since the existence of non-free area and having packages there correctly maintained made possible to run Debian at all. It takes users to explicitly install those non-free bits though and it is not automatic (and should remain as such). This increases their level of awareness wrt non-free works... which is a good thing (somehow). Also, you explained that packages in non-free or contrib areas are maintained on a best-effort basis. How is this different from main? [1] http://stefano.zacchiroli.usesthis.com/ Best Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a44cce77c882626bcb32d91f8e79c...@dogguy.org
Re: Q to all candidates: spending money
Hi, Le 2015-03-12 09:16, Lucas Nussbaum a écrit : Hi, In his platform, Neil wrote: I will spend some money we have horded. Debian currently holds approximately $200,000 at SPI alone. Our donators didn't give us money for it to be sat around in a bank account, we should spend it to make the project more successful. Neil: how will your approach to that be different from what was done in the past? On what additional things specifically do you plan to spend that money? Other candidates: what will be your approach to that? I list in my platform a few ideas: - Sprints - Mini-debconfs - Outreach (as replied in another mail). Besides, I'd like to encourage multi-team meetings (which are not more than simple sprints) to be able to work on a larger scopes than the one limited to a team. For example (only as ideas) a sprint with the Release Team and Security Team so that both can reach a consensus on which software to update during a freeze and following which criteria ; a sprint with FTP team and Wanna-Build team in the hope to get source-only uploads or arch:all rebuilds move forward. (and not speaking about the long awaited PPAs subject, which IIUC still needs much work on both sides) All candidates: how will you reconcile that with the fact that the DPL currently only has a limited vision of what funds are available, and how they evolved over time? The vision is not perfect, but we have a rough idea on how much donations we receive and how much we spend. Leaving aside DebConf's budget which puts efforts in a specific fund raising campaign, we are left with hardware replacement, sprints and mini conferences, etc... Up to now, I think we've been running with a budget between 20k$ and 30k$ for sprints and various conferences. Not having a perfect vision on our funds didn't stop past DPLs from putting in place ambitious plans (5 years hardware replacement and encouraging sprints). So unless one DebConf really cracks its budget or the of donators/donations drops drastically or some DPL starts spending money without looking at the total sum, I'd not worry much about our funds. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/34cde67e3e4a06d1ddec7935f2f69...@dogguy.org
Re: Q to all candidates: SWOT analysis
Le 2015-03-15 05:15, Paul Wise a écrit : On Sun, Mar 15, 2015 at 6:25 AM, Mehdi Dogguy wrote: - Lack of people power in some areas Which general areas would you say we have a particular need for more people in? - Generally, no interest of contributors for non-technical tasks The amount of translators we have suggests otherwise. Likewise the amount of themes we got for jessie. The newish recruits to the publicity team are another exception. That is true and I'm glad those teams have the necessary visibility to be able to recruit new blood. At the same time, the auditor team is not very active, dpl-helpers initiative didn't attract many people, debian-doc really needs people, we also lack AMs, ... Besides, about the amount of translators, your remark doesn't stand true for every language. - No roadmap How would you propose to set a roadmap? Just to be clear, I am not proposing that the DPL gains a new power and decides of the technical strategy of the project. I want to set up a process which will enable us (DDs) to give some visibility to our individual plans ; use this opportunity to see if this plan can be shared with other teams or individual DDs ; and finally have a list of goals that (more or less) shows the projects' priorities. Technically, the process will look more or less like the one used to collect ideas for Release Goals and build a wiki page with a description of each idea, names of persons that will make sure some work is being done and some criteria to give some idea on the progress. Threats: - Containers as a solution to deploy applications and services. I consider this an opportunity; imagine a future where people say this; go to Debian for your container needs, they produce secure, security-updated and backport-updated container images for these tasks/applications/blends. This could expand the amount of people using Debian in some form and the amount of package maintainers. We are all technical persons and have our idea on how to implement this in a useful and efficient way. Yet, users didn't see any tool to do that inside Debian. And I didn't see much efforts spent on this subject in Debian (but I'd be glag to be proven wrong). So, I also consider this as an opportunity and you are right to mention it. But it remains a threat as long as we don't take any counter-measure by implementing one or simply promoting an existing solution IMHO. So, it is kinda both. :-) The more concrete question at hand is whether d-i and apt-get (with their current features) are enough to deploy this new kind of environments. And in all cases, we are also not providing container images nor really documenting the Debian way to generate them. There are some procedures to make images here and there, but maybe we could centralize them in a dedicated portal or a dedicated section in the Debian wiki. This is also related to your point on the state of the documentation in general. - Complexity of new software stacks: Who's really able to debug his Gnome installation and understand all dbus-triggered stuff? It became so much complex that even power users have troubles finding answers. And this is not an isolated example. Surely this is just a matter of having debugging tools, knowing they exist and learning to use them? For D-Bus, there are bustle, dbus-monitor mdbus2 AFAICT. I certainly wouldn't expect to be able to debug a C/C++ program without valgrind/GDB/etc, nor a web application without Firebug or similar. Indeed. Thanks for pointing this out. But my point was on a more general remark to say that our job as intergrators becomes harder and harder with time and we should make sure that we have to right tools to analyse new complex situations and make sure our contributors are aware of those tools. - Potential new contributors from Arabic-speaking countries I haven't noticed any particular opportunity for this, could you mention where/how you noticed this? There are (for example) tunisian and algerian Debian mirrors and not many (or not at all) contributors or DDs from those countries. We know for sure that we have many users there but we don't see them contributing back to us. At the same time, they have very active Ubuntu and Fedora groups. Some of them are even contributing technically and not only acting as local ambassadors for those distributions. So I'd like to consider this an opportunity to onboard new people from places where we are not really represented yet. -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ae4a7fa642d1bc74407f6c2e97f1e...@dogguy.org
Re: Q to all candidates: spending money
Hi, Le 2015-03-13 19:06, Stefano Zacchiroli a écrit : On Fri, Mar 13, 2015 at 06:44:45PM +, Neil McGovern wrote: * Outreach. Every team complains (quite rightly!) about the lack of people to do the work. Yet we seem to be rather poor at actively recruiting people to come and do things for us. Outreachy is a great initiative, and I would love to see a Debian Apprentice scheme (though that's probably a bit of a stretch goal!) So, to be clear: would you authorize to use regular Debian funds to sponsor Debian participation into Outreachy (which costs ~6000 USD per intern), rather than going necessarily through dedicated fund raising campaigns at each edition? I explicitly mention in my platform that we should sponsor internship programs like Outreachy. I think that we can fund 2 slots per year. But this is also a subject that I wanted to discuss more in details with the Outreach team to which I would like to formally delegate the representation and organization of our participation in such programs. This team should have a word on this subject too. Of course, as you duly noted, this doesn't prevent us from organizing a fun raising campaign to sponsor extra slots. Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c7aacb110d880170b10f6992b3a7c...@dogguy.org
Re: Q to all candidates: SWOT analysis
Le 2015-03-13 19:25, Neil McGovern a écrit : On Thu, Mar 12, 2015 at 09:55:01AM +0100, Lucas Nussbaum wrote: Hi, You are probably familiar with SWOT analysis (https://en.wikipedia.org/wiki/SWOT_analysis). From your perspective, what are Debian's main strengths, weaknesses, opportunities and threats? Indeed, though I'm not the biggest fan of SWOT. It's often misused, and doesn't actually solve any issues on its own for strategic thinking.[0] A couple of common errors are to create a SWOT on its own, or to create a SWOT by yourself. The presence of one doesn't actually solve anything, or indeed identify a way to improve. Secondly, simply having one person's view on what should go in a box misses out the point of it - to engage and try and bring a common understanding of where we need to go. However, I've answered some of the above in a interview for the publicity team, so look out for that. I wouldn't want to spoil the work that they've put in :) I think that lucas wanted us to share our vision on Debian and SWOT as a tool to achieve that. Not more. I agree that it can be misused and is not suitable for every purpose but we are not going to build a strategy based on candidates' answers. Furthermore, interviews address lucas' question only partially. I don't pretend to be exhaustive here but I've tried to list the ones that look important (to me): Strengths: - History of the project: We've been doing this for over two decades now. We have accumulated a lot of experience and showed that our work is relevant to the Free Software and Open Source community. - Strong and large community: We have thousands of contributors and millions of users. - Largest number of derivatives based on Debian, comparing to other popular distributions. - Largest package repositories - Known for its philosophy of technical excellence and commitment to free software. - Independence Weaknesses: - Lack of manpower in some areas - Generally, no interest of contributors for non-technical tasks - Not easy to get started - Complex processes (or sometimes, not well known) - No roadmap - Financial status not clear: We have money but we don't spend it. I guess I'll be more verbose on this subject when replying about the question on fundraising. Threats: - Free (no fee) services: People externalized some part of their computation and started relying more on more on online services for their daily tasks (mails, calendars, storage, text editors, ...). - Containers as a solution to deploy applications and services. - Non-free hardware more and more common. Even our CPUs require a microcode that we are invited update blindly! - Complexity of new software stacks: Who's really able to debug his Gnome installation and understand all dbus-triggered stuff? It became so much complex that even power users have troubles finding answers. And this is not an isolated example. Opportunities: - Cloud services - Potential new contributors from Arabic-speaking countries - Post-Snowden era -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0d0bd2a0413a260b55567f5252c4c...@dogguy.org
Re: Q to all candidates: spending money
Hi, Le 2015-03-12 23:07, Martin Zobel-Helas a écrit : Hi, question to all candidates: Will you revoke 20131008134615.ga19...@xanadu.blop.info or do you think this authorization is useful? Revoking this authorization looks more counter-productive than anything else. I will not revoke it. If we are expecting highly available systems, the least we can expect is DSA being able to do such expenses quickly. I expect current and/or future DPL to ask DSA if there is something to enhance there, after more than a year of publication of this process. -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c59b31281b80bc193a5b267967330...@dogguy.org
Re: Debian Project Leader Elections 2015: Call for nominations
I hereby nominate myself for the forthcoming DPL election. -- Mehdi signature.asc Description: Digital signature
Re: To Lucas: how do you plan to push your ideas
On 03/12/2013 06:37 PM, Raphael Hertzog wrote: Hello Lucas, I've read your platform and I share your 5-years goals and I agree on most of the suggested intermediary goals to bring us closer to the long term goals. That said, it's not clear to me how you plan to achieve them. Being the DPL doesn't grant you more time to implement them yourself and your influence as DPL is limited. You said “at least you know what I consider the most important, and where I would push”. How do you expect to push your agenda for the project? I do wonder why your question is for lucas specifically? It would be interesting to hear other candidates on this too. Do you plan to recruit minions^WDPL helpers to work on each of the sub-goals? Not replying for him but his platform mentions that. Maybe you should read it? Cheers, -- Mehdi -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513f8abf.6000...@dogguy.org
Re: Finding sponsors for Debian
On 03/12/2012 09:00 AM, Wouter Verhelst wrote: Having said all that, provided we don't overdo it, having more money isn't necessarily a bad thing. If there are ways to attract more money from donators, we should do so. I don't think sending letters to companies is going to accomplish that, but that doesn't mean we shouldn't try other things. The question was precisely: what are “other things”? Can you be more explicit? Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5db20c.2020...@debian.org
