Re: Concerns about GNU Bison maintenance.
On Thu, Aug 6, 2020 at 2:58 PM Kaz Kylheku (gnu-misc-discuss) <936-846-2...@kylheku.com> wrote: > Distros still have old versions of Bison (easily as far as ten years), > possibly because they have discovered that Bison upgrades are > radioactive. In Fedora we update bison at each release. In the last 10 years we've rebased bison 10 times following each upstream release from 2.4.3 to 3.6.4 (just recently). We do not avoid bison rebases. Cheers, Carlos.
Re: what is GNU? what is a social contract?
On Tue, Feb 11, 2020 at 12:18 AM Carlo Wood wrote: > They are hostile towards the GNU project. Yes, we are opposed to the current governance structure of the GNU Project. > Therefore, there is nothing to discuss really. The correct > thing to do right now is to ignore their attempts to sow discord. My goal is certainly not to sow discord, but to engage in change that improves the governance and effectiveness of the GNU Project. > I will certainly not object to discuss *a* social contract, but not > with these people, who even created a misleading "gnu*" website, trying > to convince people they speak for the GNU project. Perhaps we > can pick this up again in a few months when things have returned > to normal :) The goal behind creating wiki.gnu.tools is not to be misleading, but to create additional tools for GNU Maintainers. Right now we're offering a git-backed wiki for GNU Maintainers to use. Cheers, Carlos.
Re: I suspect that there is no such thing as a "GNU Social Contract"
On Mon, Feb 3, 2020 at 12:49 AM J.B. Nicholson wrote: > gnu.tools' current domain registrar (namecheap.com)[1] is not the same as > gnu.org's > current domain registrar[2] (gandi.net). gnu.tools' owner is not publicly > listed in > whois but gnu.org's organizational owner is publicly listed in whois. If I > were keen > to agree to Courtès' proposal I'd wonder why the gnu.tools domain exists, if > GNU > needs a wiki for the project why not host that wiki on wiki.gnu.org, and > where one > could get official word from the GNU Project leader (which remains rms) on > which > domains are owned by the GNU Project (certainly one would expect gnu.org to > be in > that set of domains but not necessarily gnu.tools). The gnu.tools domain is not owned by the GNU Project. The domain is setup by GNU Maintainers for other GNU Maintainers. I helped setup wiki.gnu.tools. If you have any questions please don't hesitate to ask. I am a GNU Maintainer for the GNU C Library. I have been working on the GNU C Library project for 17 years. I am one of the trustees of the GNU Toolchain Fund, a Working Together Fund with the FSF. When an informal poll was taken on the private internal mailing list of the GNU Project over a dozen maintainers requested a wiki. Such a wiki was not provided, so myself and other GNU Maintainers took it upon ourselves to build a wiki we would want to use. The wiki is free to use for all GNU Maintainers. I would like to open the wiki up further for others to use, but for now we're taking small steps. > These differences suggest to me that one should be wary of what one finds on > gnu.tools. Privacy of whois information is important to avoid abuse. Cheers, Carlos.
Feedback on the GNU Social contract and new wiki.gnu.tools.
Myself and several other GNU Maintainers have been publicly discussing a GNU Social contract on gnu-misc-discuss@gnu.org and what it means to be a GNU Project volunteer. We are continuing that discussion by reaching out (by email) to all GNU Maintainers. We look forward to your feedback! Please have a look at the email you get since it has some important dates. To assist in this discussion we have created a new wiki for use by GNU Maintainers. https://wiki.gnu.tools The wiki is designed to meet the needs of GNU Maintainers who have asked for a wiki. Given the feedback it is git based with markdown support, and is an actively maintained wiki that is free software with good internationalization. Thank you for your support in making a positive change in the GNU Project. Cheers, Carlos.
Re: Moderation
On Tue, Jan 14, 2020 at 2:25 PM Jean Louis wrote: > Then why did you start in the first place with defamation of GNU > project and RMS? Ludovic is asking about what is being written on the mailing list, but your response is a question about a statement that has nothing to do with what is being written on the mailing list. Your statement does not logically follow Ludovic's question. What does your alleged off-site defamation have to do with what is being written on this mailing list? If you find a case of defamation posted to this mailing list then please raise this with Brandon and Mike the moderators. Cheers, Carlos.
Re: suspending FSF contributor agreements with immediate effect
On Tue, Jan 14, 2020 at 10:39 AM Daniel Pocock wrote: > FSF will not change unless somebody gives them a strong reason to change. > > For example, if GNU developers write the following email to FSF, that > will bring change. > > Each developer needs to make their own decision if they will send the > email. RMS has previously suggested he would not like people to > completely abandon the agreements. The email template below is only for > a conditional suspension of the agreement. Nobody can tell you to > continue assigning[1] your rights to FSF if you want to wait for more > clarity about FSF's future. > > You can still keep coding during the suspension: if a significant > quantity of code is published and virtually embargoed like this, it > creates an incentive for FSF to satisfy those people and gain rights > over that code. I can empathize with your frustration over the current state of affairs and the lack of transparency (including timely updates to members of the FSF). However, what you propose is seems like a measure of last resort. May I encourage you to help the current GNU Project volunteers working to define a governance model that is organized from the bottom-up? A governance model that rallies around the community to engage them in the goals of the GNU Project, not just the outcomes. We absolutely need people like you to promote the goals of the GNU Project. Cheers, Carlos.
Re: A summary of some open discussions
On Mon, Jan 6, 2020 at 5:16 AM Brandon Invergo wrote: > Mark Wielaard writes: > > >> There is no such thing as a FSF steward, GNU maintainers are appointed > >> by RMS/GAC. The FSF has no say in the topic. You've keept > >> misrepresenting this over and over again. > > > > This is just a legal technicallity. The FSF has oversight > > responsibility over the GNU project. That means that the FSF needs to > > determine that GNU maintainers operate in a manner consistent with > > FSF's exempt purposes, have the needed expertise and that their > > activities can be monitored by the FSF board. So GNU Maintainers and > > Steering committees are technically appointed by the FSF (previously > > RMS when he was FSF president and board member) as stewards of GNU > > packages. Basically GNU maintainers serve at the pleasure of the FSF. > > This is absolutely false. Which part? The FSF is a tax-exempt charity that has oversight responsibilities for the work being done with the resources it owns. So at least that part is true. The last two sentences are a reframing of the existing governance structure based on the legal requirements placed on the FSF by its tax-exempt status, which is why Mark uses the word "technically" not "literally." You appear to have interpreted this as the literal meaning, which is likely not Mark's intent. As Ludovic says, please assume good intent. You can ask Mark what he meant by it before calling all of it, incorrectly so, a falsehood. I agree with Ludovic and Andreas' comments downthread that when you join a volunteer organization you join it to further the goals of the organization. Cheers, Carlos.
Re: Setting up a wiki for GNU Project volunteers?
On Wed, Dec 18, 2019 at 5:22 AM Alfred M. Szmidt wrote: > You say we must follow requirements and policies, but yet you > purposely rejected it when you removed text that was explcitly asked > to be kept by RMS in the glibc manual. Which is it? Yes, we must follow requirements and policies. Yes, I explicitly rejected the request to keep the abortion-related cartouch in the glibc manual. I don't see that those two things are contradictory. > I agree with Brandon, in that wikis are terrible for documentation > purposes, and think that the quality of the glibc/gcc/... manuals, for > example, has become much worse due to the fact that a wiki is being > used. Much of it is very hard to navigate, and find relevant > information -- not to mention that one is required to have a network > connection. And some parts might be very very wrong. A good manual > takes concious effort to update, since a wiki doesn't it will always > be a much worse place for writing down things. The wiki I'm proposing would be legible offline since you could check it out. I disagree with you about the glibc manual. The number of contributions to the manual has gone up over the years and high quality text is being added. If you have concerns please raise them on the main developer mailing list to discuss. The wiki for glibc is completely different documentation and contains no API documentation, all of that is in the glibc manual. I agree a good manual takes conscious effort to update. I am not suggesting the glibc manual be put into a wiki. Though other packages are free to choose as they wish, the GNU Coding Standard only says texinfo is the preferred format. This effort to make the manual better has been helped by the communities organization, and that includes a wiki. > The GCS, etc, are maintained by people who feel that they don't have a > use for a wiki or that it would be useful for the purpose. GCC, the > GNU C library, are maintained by people who feel that a wiki is useful > for their purpose. Today, we have a nice balance of people being able > to make things work for them, but you are trying to force everyone > into your workflow. I am not forcing anyone into any workflow. I am looking at creating a wiki for use by those who find wikis useful. My belief is that we should enable developers where possible and support their workflows. If, in the GCS, with the volunteer time you have, you want to ask people to post to the mailing list, that's perfectly fine. Cheers, Carlos.
Re: Setting up a wiki for GNU Project volunteers?
On Fri, Dec 13, 2019 at 11:00 AM Brandon Invergo wrote: > In the interest of public transparency and honesty, you should have > mentioned that Richard has already explicitly and unequivocally rejected > the proposal for a public, project-wide wiki. Therefore, the following > question must be emphasized: Richard, as do you, have the right to reject anything you dislike. Do you have a public URL to Richard's statement? I'm happy to publicly discuss having a wiki, and what concerns you have. For example, if you are concerned about the content being confused for official content, how might we resolve that? Would a non-gnu.org URL suffice? I am interested in your own opinion. I don't expect you to speak for others. > > Where could we host a wiki like this without causing confusion with > > official project content? > > Unless that decision changes, any wiki discussed here is necessarily > unofficial and any proposed content is in no way implicitly endorsed or > supported by the GNU Project. I care about enabling GNU Project volunteers to do their best work. I care about engaging with GNU Maintainers and building a stronger GNU Project community. > Personally, I've found that in most cases wikis are an inefficient means > of active collaboration and discussion, that they accumulate outdated > cruft too quickly for casual documentation to be anything more than > ephemerally useful, and that they're too mutable for maintaining > important documents. I disagree that they are inefficient. We have efficiently used a wiki in glibc, gcc, and gdb for almost a decade, and these are three of the largest projects that are part of the GNU Project. It is exactly a wiki's low-cost mutability that makes them useful. When you say "important documents" you need to explain what aspects are important to you. Just like saying something is "better" you have to explain "better at what?" Are these documents important for policy reasons? Are they important to developers day-to-day process? > Any best practices, advice, etc. would be better > placed in the coding standards or maintainers documents. Active > collaboration of small teams does not need a project-wide wiki and can > be more efficiently achieved by ad hoc methods. Core documentation of > the project should only be on the main website, and by definition it > should not be easy to change. Not all documents have the same requirements. The "GNU Coding Standards" is a good example of a document that has no real official requirement to be followed, and my opinion is that it should have more liberal updates by programming language experts from the GNU Project volunteers with modern experience in the tooling used to develop such programs. I have no interest in proposing changes to the GCS unless and until it is publicly documented how the process of updates will work and who will review the changes and authorize their acceptance. Policy documents should absolutely live in very highly controlled repositories and go through a specifically crafted processes for change. We must follow many of the requirements in the "Information for maintainers of GNU software" and that document should be as clear as possible. Lastly, even small teams can make effective use of wikis. I have run a team of ~4 developers for a long time and we make effective use of wiki or wiki-like software for collaboration. My impression from the dozens of other developers I've spoken to on this topic indicates the same effective use of wikis. Most ad-hoc mechanisms boil down to using wiki-like software, either etherpad (which we could run too, and it's FOSS) or pastebin (available under CC0 for Stikked). > Gnome's wiki is a perfect example of why it's a bad idea. No. It is your opinion that it is a bad idea. Have you asked GNOME developers if they find the wiki useful? The top-level page and maintainer's pages have all seen updates in 2019, with notes that look valuable and useful to me. > All this makes finding current and correct information about any details > about Gnome to be too difficult > without having to carefully vet everything against other sources. Not all documents have the same requirements. Are you a user of GNOME? Looking for official GNOME documentation? Go here: https://help.gnome.org/ Are you developing GNOME applications? Go here: https://developer.gnome.org/ Are you an existing GNOME developer? Working on FreeBST jhbuild? Go here: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Are you a new GNOME developer? Looking for a list of mailing lists to subscribe to? https://wiki.gnome.org/Newcomers/BeforeWeBegin The GNOME wiki is clearly a developer-focused wiki, so you can't call it a bad idea that it doesn't succeed at needs it was never meant to meet. There are lots of pages on the GNOME wiki which are updated and current and are clearly being used to keep GNOME developers in sync and focused with summarized and useful information. I refute your claim that wikis are
Re: Setting up a wiki for GNU Project volunteers?
On Wed, Dec 11, 2019 at 2:12 AM Federico Leva (Nemo) wrote: > > Carlos O'Donell, 10/12/19 20:25: > > Selection criteria for a wiki? > > It must support multilingualism and have the best-in-class support for > i18n, which is currently a GNU high priority. > <https://www.fsf.org/campaigns/priority-projects/internationalization> I believe that Dokuwiki meeds best-in-class support for i18n. (1) Is i18n possible? Yes. It is possible to localize dokuwiki: https://www.dokuwiki.org/localization (2) Is l10n possible? Yes. The current progress against the various languages is here: https://translate.dokuwiki.org/dokuwiki You can *immediately* submit translations to the developers via the web UI for incorporation into the next release. Do you think that meets our needs? Cheers, Carlos.
Setting up a wiki for GNU Project volunteers?
Wikis are useful software that allows developers to work collaboratively and quickly on informal documents that are part of the day-to-day running of the packages or project activities. This includes documenting such things as: - Email thread summaries - Status updates - Meeting notes - Summaries of discussions around best practice activities In researching this kind of wiki setup I have discussed the issue with various GNU Maintainers and the consensus seems to be that such a system should have the following qualities: - Based on a VCS e.g. git - Uses a supported wiki platform e.g. dokuwiki - With a sensible markup e.g. markdown plugin for dokuwiki What do people think about setting up a wiki? Several packages already have wikis like: The GNOME Project (https://wiki.gnome.org/) The GNU C Library wiki (https://sourceware.org/glibc/wiki/) The GNU Debugger wiki (https://sourceware.org/gdb/wiki/) The GNU Compiler Collection wiki (https://gcc.gnu.org/wiki) However, we have no good central community wiki to put document those things listed above. Does anyone have a strong opinion on which wiki software should be used? Selection criteria for a wiki? I'm suggesting dokuwiki + git. Access controls for the wiki? Anyone who volunteers or wants to volunteer their time to the GNU Project? Where could we host a wiki like this without causing confusion with official project content? Lastly, for direct discussion of the GNU Coding Standards and Information for GNU Maintainers please see https://lists.gnu.org/mailman/listinfo/bug-standards. Wiki summaries could feed into discussions on bug-standards or bug-standards discussion could get summarized into the wiki to build consensus for particular changes. Looking forward to any feedback volunteers want to provide. Cheers, Carlos.
Re: A GNU “social contract”?
On Tue, Dec 10, 2019 at 8:21 AM Carlos O'Donell wrote: > > On Sat, Nov 9, 2019 at 12:44 PM Andreas Enge wrote: > > > > On Thu, Nov 07, 2019 at 09:46:56PM +0100, Ludovic Courtès wrote: > > > Thanks, Andreas, for this new version! Some comments below. > > > > They are integrated into the attached new version. For good measure, > > I have capitalised "GNU System" as you did and thrown in a few italics > > as suggested. > > This looks great! +1 from me. > > I like that we have 4 straight forward items. > > Cognitively I might like 5 items. Humans tend to like 3, 5, or 7 items. > > You can count 5 on your hand. > > Some cultures really like 5 item lists. Some cultures dislike the > number 4 and find it bad luck. 5. Reserved for future use! Just put it into the contract and leave it for future use ;-) Cheers, Carlos.
Re: A GNU “social contract”?
On Sat, Nov 9, 2019 at 12:44 PM Andreas Enge wrote: > > On Thu, Nov 07, 2019 at 09:46:56PM +0100, Ludovic Courtès wrote: > > Thanks, Andreas, for this new version! Some comments below. > > They are integrated into the attached new version. For good measure, > I have capitalised "GNU System" as you did and thrown in a few italics > as suggested. This looks great! +1 from me. I like that we have 4 straight forward items. Cognitively I might like 5 items. Humans tend to like 3, 5, or 7 items. You can count 5 on your hand. Some cultures really like 5 item lists. Some cultures dislike the number 4 and find it bad luck. Cheers, Carlos.
Re: Women and GNU and RMS (was Re: something else)
On Sun, Nov 3, 2019 at 10:32 PM Ruben Safir wrote: > Nobody believes this except for a few hysterical lunitics. Your > posting this as such is another form of disinformation and an attack on > the intelligence of the GNU community. This is unkind and doesn't contribute to a constructive discussion of the issues at hand. Cheers, Carlos.
Re: List posting rules
On Sun, Nov 3, 2019 at 4:02 PM Alfred M. Szmidt wrote: > No, or minimal moderation -- as has always been the case for GNU > lists. It is better to let a off-topic message through, and > communicate to the user of the case than to reject it. It is better > to ask the person to use a kinder tone than to reject a message. > > Moderation is hard, it is annoying, but the general rule is to always > let messages through. Spending the extra effort in creating a kind > environment, a hard, and long process, is a worth while goal -- even > if that means sometimes accepting messages that might "break the > rules"... Yup, that's what we agreed to with Mike Gerwtiz and Brandon Invergo's advice. I think it's the right way forward. Cheers, Carlos.
Re: list moderation
On Sun, Nov 3, 2019 at 12:41 PM Brandon Invergo wrote: > For the past month or so, every message to the list has been subject to > moderation, so-called "emergency moderation". It has become clear that > the moderation was being used in a biased manner. We have decided to > remove Mark and Carlos as moderators/admins and to turn off the > emergency moderation. We will not place any restriction on the topic of > discussion beyond what is outlined in the pre-existing list guidelines. > > This is *not* an invitation for open flames. Please continue to abide > by the Kind Communication Guidelines. We will closely monitor the > discussion and we will take appropriate actions as necessary. Thanks to all of those that provided input into the list moderation and censorship discussions. My moderation is certainly biased towards posters that write well, and argue without attacking the original poster, and create an environment for effective communication. Lots of people on this list were able to do that and their posts were approved. These guidelines are long-enshrined in the list description. Enforcement is up to the volunteers who run the list. In all transparency I volunteered to moderate the list, because nobody else was actively moderating, and Mark and I were worried about toxic discussions derailing the conversations. Mark and I were given moderator and admin access because we were trusted to do that. We are long-time GNU Maintainers, and our goal was specific. You don't get list moderator or admin access without that trust. I don't see that we have abused that trust. We did alter the list description to include an updated description of the kind of moderation that was going to happen, however it was for all intents and purposes an extension of the existing rules that say anything can be discussed. I don't clearly understand why Brandon or Mike removed us from volunteer moderation. If they want us to help out with the list again, I'm happy to help. We engaged with them to discuss how we should handle the moderation issue, and I thought we had achieved a consensus on that. We were going to post about shortly, and effectively do what Brandon is doing right now. However, I'm disappointed that there has been a sudden decision to remove us as volunteers. I think this comes down to clearer roles and responsibilities in the GNU Project, which is something we are all already talking about. All-in-all it doesn't change the end goals we are working towards. I encourage everyone to follow the GNU Kind communication guidelines when posting. I encourage all of you to call out unkind behaviour. I encourage all of you discuss about GNU Project governance while avoiding specific discussions about people and their capabilities. Cheers, Carlos.
Re: List posting rules
On Sat, Nov 2, 2019 at 2:01 PM Dora Scilipoti wrote: > You, Carlos O'Donell, and your fellow censor Mark Wielaard, should NOT > be the moderators of this list. You are both signers of a public > document that calls for the removal of Richard Stallman as the leader of > GNU, namely the "Joint Statement." Therefore, your natural bias is to > accept messages that work towards your goal while rejecting those that > oppose it. I agree that I likely exhibit bias, to that end we have invited others to moderate. Brandon Invergo and Mike Gerwitz are also moderators, specifically to help avoid this kind of bias. I don't see why I should not be a moderator. Everyone has some kind of bias. Moderation is a difficult task. The goal is to keep the list discussions on-topic, governance should be about governance not people, and existing list rules should be followed. > For example, given that the declared purpose of this is list is to talk > about governance, Sandra Loosemore's messages were in violation of the > following rule, and yet they were approved: The purpose of this list is spelled out in the list description. Sandra didn't post a discussion about governance, she didn't talk about restructuring the GNU Project. She spoke only about existing leadership. Governance discussions, those talking about governance models, and how to restructure GNU, should stay on topic, and should *not* talk about people and their capabilities. > While another message, carefully drafted to refute her considerations in > the clearest possible way, was rejected: You just posted it, but it was a thread about list posting rules and a discussion of those rules, so it's on topic, and not repetition by Marcel, nor is it a thread that has degenerated into name calling, tit-for-tat, or flaming (thank you for that). I have indicated to Marcel that if he wishes to repost messages for review that the moderators (4 of us) are willing to review it again. I have seen one repost by Marcel that was unkind, particularly with his displeasure at being moderated. This is a GNU list, and I urge people to hold themselves to a high standard of writing, and decorum in discussion. Cheers, Carlos.
Re: List posting rules
On Fri, Nov 1, 2019 at 9:20 AM Dora Scilipoti wrote: > Please note that the message posted by a woman on Oct 30 contains a > repetition of what we all have already read on dishonest media. Sandra Loosemore posted her opinions for the first time. She didn't repeat herself. Cheers, Carlos.
Re: Women and GNU and RMS (was Re: something else)
On Thu, Oct 31, 2019 at 7:29 AM Ruben Safir wrote: > Just because YOU say he is defending sexual abuse of minors doesn't make > it so, no matter HOW many times you say it. That is the fact and > hiding that fact behind charges of sexism is immoral. Please follow the rules of this list. Repetition should not happen. You have made your case. Cheers, Carlos.
Re: gnu-misc-discuss@gnu.org is premoderated
On Mon, Oct 28, 2019 at 4:30 PM Florian Weimer wrote: > > * Carlos O'Donell: > > > The GNU C Library main development list was pre-moderated for almost 5 > > years. During that period we moved a lot of conversations to the glibc > > help mailing list using moderation. This helped new users get started > > in a more welcoming environment. Just an example of a public technical > > FOSS list that used moderation. Most people didn't know it was > > pre-moderated. > > Interesting. When was this? This must have been at a time when > contributing to glibc was … difficult for non-technical reasons, right? The moderation was in effect from 2008-2012. Yes, contributing to glibc was difficult at this time for non-technical reasons. Cheers, Carlos.
Re: A GNU “social contract†?
On Sun, Oct 27, 2019 at 6:19 PM Ludovic Courtès wrote: > > Hi Alfred, > > a...@gnu.org (Alfred M. Szmidt) skribis: > > > What GNU maintainers agree to is very small, it is only to follow the > > policies that we have. They don't need to go beyond that, which is > > what "uphold" would imply. > > Exactly, that’s the change we’re proposing: members of the project > (maintainers and contributors alike who want to formalize their > affiliation with the project) would “sign” the social contract, meaning > that they commit to upholding the values defined therein. > > As you note, this would be “stronger” than the current situation where > maintainers are not expected do be willing to defend the project’s > values. I also think that stronger commitment from maintainers would actually engage them more in the project. Cheers, Carlos.
Re: gnu-misc-discuss@gnu.org is premoderated (was: ML posting issues)
On Mon, Oct 28, 2019 at 10:21 AM Dmitry Alexandrov <321...@gmail.com> wrote: > > Mark Wielaard wrote: > > On Mon, Oct 28, 2019 at 05:22:48AM +0300, Dmitry Alexandrov wrote: > >> Iʼd like to report that my message number d0eidcqu.321...@gmail.com > >> (below), sent a day ago to gnu-misc-discuss@gnu.org (which I am subscribed > >> on and usually have no problems to post to), had not landed to the archive > >> [0] for unknown reason — I did not get any failure notification. > > > > The list is [pre]moderated, simply wait till a moderator accepts or rejects > > your messages. > > Funny. Either the moderators were so efficient earlier so I never noticed > that, or thatʼs a fairly recent policy, that was introduced secretly (I do > not see any announcement). May I ask, which it is? I placed the list on moderation to help with cooling down heated discussions. It is entirely within the normal bounds of list management to use moderation. Cheers, Carlos.
Re: “GNU software is distributed under the terms of [copyleft] licenses” (was: A GNU “social contract”?)
On Sat, Oct 26, 2019 at 5:03 PM Mark Wielaard wrote: > > On Sat, 2019-10-26 at 02:35 +0300, Dmitry Alexandrov wrote: > > Ludovic Courtès wrote: > > > * GNU licenses uphold user freedom > > > > > > The GNU Project has designed software licenses to ensure developers > > > cannot strip off user freedom from GNU software—“copyleft” > > > licenses. GNU software is distributed under the terms of these > > > licenses. > > > > Sorry, but thatʼs simply untrue. Few GNU software packages are > > under lax, non-copyleft licences, namely: ncurses, nana, speex. And > > there might be a good reason for that [1]. > > I agree. It would say something like "We prefer to distribute under the > terms of these licenses." > > This is also partly why I would recommend trying to merge points 1 > (freedom), 2 (uphold freedom) and 4 (beyond software freedom). That > makes it easier to explain what compromises we do and do not make to > uphold user freedom. That sounds like a good compromise. Cheers, Carlos.
What is governance and to whom would it extend to in the GNU Project?
I wanted to kick off a conversation about what is a governance model, and to whom it would apply. A governance model would apply to all of the people who are part of the GNU Project, and so discussing these two points makes sense to me. I look forward to any feedback about this. What is a governance model? A governance model should provide: * Organization and structure. * Includes establishing authority. * Define roles and responsibilities. * Help people answer questions like: * "Why are we doing this?" * "Who needs to know about this?" * "Who is responsible for this?" * Create a feedback loop within the model to allow changes over time. What benefits does a governance model provide? * Clearly defined roles make it easier to get stuff done. * Coordination is improved between various parts of the project. * Effectiveness improved since responsibilities clearly spell out who needs to know things. Next, who is a part of the GNU Project? It's fairly straight forward to say the following people are part of the GNU Project: * GNU Maintainers (as seen in the 'maintainers' file). This is a narrow view though and leaves out a lot of really important people: * People working on advocacy and policy. * Developers working on GNU packages (bug submission, triage, wiki gardening etc.) * Anyone supporting the GNU Project directly with non-developer roles. * IT admins, project management, release managers, package review, mentoring/coaching. ... basically anyone involved in the day-to-day running of the GNU Project. Governance should extend to all of the people in the community via the defined roles and responsibilities. In summary: - Governance provides clearly defined roles, makes it easier to coordinate, and grow an organization. - A governance model brings benefits to all the GNU Project. Cheers, Carlos. ___ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
Re: Turning GNU into a bottom-up organization
On Tue, Oct 22, 2019 at 1:55 PM DJ Delorie wrote: > Even if we all agree on the "big picture simple answer" the details and > "best practices" are just as important. > > Do you have any suggestions for filling in these details? The day-to-day running of things should certainly be documented somewhere. I have suggested wiki.gnu.org as a central place where the community can come together and document best practice. Even if the wiki is eventually codified into a real manual, it has to start somewhere and grow from there. Cheers, Carlos. ___ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
Re: Turning GNU into a bottom-up organization
On Tue, Oct 22, 2019 at 10:21 AM Ruben Safir wrote: > > On 10/22/19 4:31 AM, Mark Wielaard wrote: > > That is a different organization model. > > > Yeah, I'm not interested in anything that reduces RMS's influence and > control of GNU at this point. I think he has been abused and I just > don't carer anymore. If you don't like how he does things, I would > suggest you find other organizations or project to work on. I appreciate your perspective where a single leader handles the entire project. Do you have an opinion on how a project continues beyond the original leader? Does someone new have to be nominated? Cheers, Carlos. ___ gnu-misc-discuss mailing list gnu-misc-discuss@gnu.org https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
