Re: Talk/event proposals "Closed source"
> "CK" == Carl Karsten writes: >> You can see last year's schedule¹ All that looks good. But I am worried about what we don't see: the rejected items. Maybe in the future have a radio ( ) Only make my proposal public if it is approved. ( ) Make my proposal public now, even though it hasn't gotten approved yet. Also keep it public, even if it doesn't get approved. And have a link to see all public pending proposals. Also have a link: your proposal will be sent to the Content Team, who are [Bob, George...], for review. They will tell you by April 35th their decision. If you also want to join the Content Team, press here. Anyway, I am worried that Larry might submit proposal A, whilst Mitch might be working on a very similar proposal... but due to the closed nature of the system, instead of just joining up with Larry, Mitch toils day after day building his independent proposal, because he is unaware of Larry's. Or Frank might submit proposals A, B, and C, thinking if all are accepted, than he won't bother submitting D, E, F. As there won't be enough time. But in fact A, E, F are the ones the committee would have liked, but alas it is too late now... etc. as there is no second round maybe and if there was a more open process he could have got feedback earlier to find which are the ones people like more. But then he is also too embarrassed to rally support for his proposals by posting them to debconf-discuss etc. instead of waiting for them to first be approved.
Re: Talk/event proposals "Closed source"
Reply at bottom :- On 21/03/2018, 積丹尼 Dan Jacobson wrote: >> "CK" == Carl Karsten writes: >>> You can see last year's schedule¹ > > All that looks good. But I am worried about what we don't see: the > rejected items. > > Maybe in the future have a radio > ( ) Only make my proposal public if it is approved. > ( ) Make my proposal public now, even though it hasn't gotten approved > yet. Also keep it public, even if it doesn't get approved. > > And have a link to see all public pending proposals. > > Also have a link: your proposal will be sent to the Content Team, who > are [Bob, George...], for review. They will tell you by April 35th their > decision. If you also want to join the Content Team, press here. Correction, surely you mean April 5th than April 35th unless we are talking about another time dimension ;) > > Anyway, I am worried that Larry might submit proposal A, whilst Mitch > might be working on a very similar proposal... but due to the closed > nature of the system, instead of just joining up with Larry, Mitch toils > day after day building his independent proposal, because he is unaware > of Larry's. > > Or Frank might submit proposals A, B, and C, thinking if all are > accepted, than he won't bother submitting D, E, F. As there won't be > enough time. But in fact A, E, F are the ones the committee would have > liked, but alas it is too late now... etc. as there is no second round > maybe and if there was a more open process he could have got feedback > earlier to find which are the ones people like more. > > But then he is also too embarrassed to rally support for his proposals > by posting them to debconf-discuss etc. instead of waiting for them to > first be approved. > Dear Dan, There may be a germ of an idea but we would need to more people from the local team who are in Hsinchu and don't have any bursary needs just to arrest any potential conflict of interest claim later. Although the idea has merit, it would be a bit premature without having a rough number of talks, workshops and events proposed, the ones which were passed officially, ones which took part of lightning talks to arrive at rejected numbers to have an idea of rejections. And the data would have to be of at least the last two debconfs to have coherence at all. Those numbers would to be shared by Gunnar which I hope doesn't add more to his troubles than he already is in. It would also mean adding new bits of code to wafer and if I may suggest having at least two-three people looking at it through the process and the system having some way of informing who is looking at your proposal. If we were to make it transparent then how many votes were for and against a proposal. No names, just votes just how General resolutions work. It also means more fleshed out team then just Gunnar doing all the work and someway of measuring and reflecting the other 1-2 people's contributions otherwise it might all end up being up all in Gunnar's lap again with potential burnout possibility which we wouldn't want for any reason. There is another thing that potential presenters have, over-commit and polishing the idea. Excerpt taken from yesterday's blog post - https://flossexperiences.wordpress.com/2018/03/20/debconf-2018-mate-1-2-0-libqalculate-transition-etc/ "The best advice I can give is to put your proposal in and keep reworking/polishing it till the end date for applications is near. At the same time do not over commit yourself. From a very Indian perspective and somebody who has been to one debconf, you can think of the debconf as a kind of ‘khumb‘ Mela or gathering as you will. You can definitely network with all the topics and people you care for, but the most rewarding are those talks which were totally unplanned for. Also it does get crazy sometime so it’s nice if you are able to have some sane time for yourself even if it just a 5-10 minute walk. " There is another danger that the reviewers would need to watch out for. Not having prefixed ideas ideas as to what would bring value to the conference. For instance, if people see that people working on SQL or JAVA or some other equally big package has more consideration than small everyday utilities it would adversely impact both our motto of ' Universal Operating System' as well as have dangers of making it more 'corporate' as usually big packages, if they are to stay around to be relevant needs corporate sponsorship to remain relevant. Not to spark any debates, but that can be easily seen by how GNOME has grown and KDE has sort of wilted after Nokia's departure. Lastly, in theory I do like the idea of one or more people collaborating or even discarding ideas if they see other people having the same idea. But as in everything else, collaboration is easier said than done. Students for instance might reject or not put up proposals if they see somebody already submitting an idea. It takes anywhere between 2-5 hours or even more fleshing out an proposal . Adding to deal
Re: Talk/event proposals "Closed source"
On Wed, Mar 21, 2018 at 04:42:52PM +0800, 積丹尼 Dan Jacobson wrote: > But then he is also too embarrassed to rally support for his proposals > by posting them to debconf-discuss etc. instead of waiting for them to > first be approved. rallying for support on debconf-discuss and twitter and whatnot to overcome the decision of the content team for me would be an indicator that rejecting the talk was a good idea. for the rest of your mail: i think you have little clue how this works out in practice, so your assumptions are deeply flawed and thus I will not participate in this thread anymore. just a helpful advice: if you further want to enter fantasialand, I suggest you suggest making the sponsorship decisions in the open. That would be another bad idea. sorry. -- cheers, Holger signature.asc Description: PGP signature
Re: Talk/event proposals "Closed source"
On 20.03.2018 23:07, Carl Karsten wrote: > Can someone elaborate on why > "unfortunately means rejecting some." > is a reason to keep anything about this secret? Because if we make public the rejection, less people will submit talks. Debian (and Free Software) communities suffer of the impostor syndrome. Additionally, having own name in a rejection list, forever accessible, could seem not so good for future employment. Keeping secret rejection allow us to get more submission (and good one). ciao cate
Re: 回覆: DebConf18保險相關事宜
On Mon, Mar 19, 2018 at 02:15:32PM +0800, ijbuj...@gmail.com wrote:
> 你好，
>
> 保險公司方面表示，目前的方案是套裝組
> 需要我們提供
> 1.受保人(單位) 名稱，需有核對之印鑑
> 2.受保地點
受保單位: 財團法人開放文化基金會 (https://ocf.tw/)
受保地點: 國立交通大學 光復校區
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
DebConf18 Team Meeting - Mar 22 2018 14:30 UTC
Hi,
We will have a DC18 team meeting at Mar 22 2018 14:30 UTC. Please help
to update meeting agenda at http://deb.li/3OYuV.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Re: Talk/event proposals "Closed source"
OK keep them closed. But at least at the bottom of https://debconf18.debconf.org/talks/new/ mention (before he hits the submit button) that "Your proposal will be held for review and only will be made public if approved." Else it might take weeks for him to find that his e.g., https://debconf18.debconf.org/talks/25/ was giving 403 Forbidden to some users. Indeed the "Any notes for the conference organisers? These are not visible to the public." on the last textbox might lead users to think that proposals are public from the start. So fine, keep the closed policy. But at least on the form state the policy. Indeed, with confidence that their rejected proposals won't be made public, maybe you will get more proposals. Currently submitters don't know if their proposal will be made public once they click submit, or not. So at least tell them, before they hit submit.
Re: Talk/event proposals "Closed source"
On Wed, Mar 21, 2018 at 9:27 AM, Giacomo Catenazzi wrote: > On 20.03.2018 23:07, Carl Karsten wrote: > >> Can someone elaborate on why >> "unfortunately means rejecting some." >> is a reason to keep anything about this secret? > > Because if we make public the rejection, less people will submit talks. > > Debian (and Free Software) communities suffer of the impostor syndrome. > > Additionally, having own name in a rejection list, forever accessible, > could seem not so good for future employment. > > Keeping secret rejection allow us to get more submission (and good one). > OK, unfortunate, but yeah, such is reality. thanks. > ciao > cate
Re: Talk/event proposals "Closed source"
Reply in-line :- On 21/03/2018, 積丹尼 Dan Jacobson wrote: > OK keep them closed. But at least at the bottom of > https://debconf18.debconf.org/talks/new/ > mention (before he hits the submit button) that > > "Your proposal will be held for review and only will be made public if > approved." > Actually, from what little I have observed, all talks held for review except for invited talks. For instance, this year we have Minister Teng (hope spelled it right) who would be sharing her understanding and hopefully kickstarting more of FOSS initiatives in Taiwan and surrounding areas. Which also sort of reminds me and I haven't seen it in any communication on debconf-team yet, has there been any attempts to get the press involved. With the Minister present, it might be possible have sound-bytes or even a TV-byte which might make more people sit up and take notice about free software in general and Debian in particular. It may be possible to also have a minute or two of Chris sharing about Debian with his DPL hat on and interaction with the lay public. For that to work, we would need to have a press team who have good contacts with the local press. > Else it might take weeks for him to find that his e.g., > https://debconf18.debconf.org/talks/25/ > was giving 403 Forbidden to some users. > > Indeed the "Any notes for the conference organisers? These are not > visible to the public." on the last textbox might lead users to think > that proposals are public from the start. > Actually what could be done is to say something at the start of the proposal itself For instance, something on the lines of ' All proposals will be kept private until they are approved. The last of date of submission is 27-06-2018 without exceptions. The approval process will start after that and would end on 27-07-2018 or some deadline like that. Whatever deadlines are given have to be approved by the content-team as they would be the ones contributing both their time and expertise in evaluating the proposals. I am a terrible writer, maybe somebody whose first language is English might be more concise and perfect. https://debconf18.debconf.org/talks/new/ > So fine, keep the closed policy. But at least on the form state the > policy. > > Indeed, with confidence that their rejected proposals won't be made > public, maybe you will get more proposals. > > Currently submitters don't know if their proposal will be made public > once they click submit, or not. So at least tell them, before they hit > submit. > > The above seems doable, just need to find an English language warrior ;) -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
