#40: Enforcing the code of conduct
-------------------+---------------------------------
Reporter: duffy | Owner:
Status: new | Priority: normal
Component: Legal | Keywords: coc, code of conduct
-------------------+---------------------------------
See this post from the outreach-list regarding the actual enforcement of
the code of conduct as currently written:
https://lists.fedoraproject.org/pipermail/outreach/2015-July/000067.html
Langdon asked that this be made a ticket for council discussion, with the
concern that an unenforceable / consequence without an SOP is a threat and
isn't the right way to go:
https://lists.fedoraproject.org/pipermail/outreach/2015-August/000073.html
For reference, the actual text is:
"FUDCon brings together contributors and users from all over the world and
this diversity is one of our greatest strengths. This diversity however
can also lead to communication issues and unhappiness. Attendees are
required to be considerate and respectful of each other. This includes,
but is not limited to:
- "Refraining from rude behaviour
- "Refraining from any sort of harassment or discrimination (based on
ethnic background, religion, gender, sexuality, body shape, disability,
geographic location, sports team, preferred operating system or anything
else)
- "Obeying local laws
"Attendees who are in violation of this policy may be subject to removal
and banning from FUDCon (and future Fedora events). Whether an attendee is
in violation is at the sole discretion of the conference organizers.
Anyone with a possible concern relating to the code of conduct is
encouraged to either email Rupali Talwatkar or talk directly to one of the
designated FUDCon volunteers. Designated FUDCon volunteers will have a
dark blue coloured VOLUNTEER badge."
The line of particular concern here is:
"Attendees who are in violation of this policy may be subject to removal
and
banning from FUDCon (and future Fedora events)."
--
Ticket URL: <https://fedorahosted.org/council/ticket/40>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#43: Create the Fedora Public Budget Page
-------------------------+-------------------------------------------------
Reporter: decause | Owner: decause
Status: new | Priority: normal
Component: General | Keywords: budget, websites, FCL, transparency,
| community
-------------------------+-------------------------------------------------
As per the results of our council discussion here
(https://lists.fedoraproject.org/pipermail/council-
discuss/2015-October/013742.html) we are heretofore establishing a new
page (wiki or otherwise) that will track the timeline and particulars of
the Fedora Public Budget. It shall include:
Budgetary Components, Projected and Adjusted for each fiscal year:
- Regional Budget Allocations (APAC/EMEA/LATAM/NA)
- Fedora Premier Event Budgets (FLOCK, FUDCon)
- Central Discretionary Fund (approved by Council)
- FAD specific Budgets
Budgetary Milestones and Timelines:
- August: In person meeting at FLOCK
- September: Proposed budget components and metrics from each region
- October: Ratification of Proposed Budget by Council
- March: Confirmation of Received budget w/ Adjustment Meeting
- Quarterly Check-ins with Regional Treasurers
- Halfly approvals of Regional Funds, pending metrics and outcomes
reporting
If there are other details or resources that should be included on this
page, feel free to leave them in the comments below. I would propose that
this page eventually be made available at http://budget.fedoraproject.org
--
Ticket URL: <https://fedorahosted.org/council/ticket/43>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#16: Periodic contributor survey
---------------------+-------------------
Reporter: mattdm | Owner:
Status: new | Priority: normal
Component: General | Keywords:
---------------------+-------------------
This is a tracking ticket for establishing a process by which we get
regular feedback from the Fedora contributor base.
This is a companion to https://fedorahosted.org/council/ticket/1. The
desired goals, methodology, and basically everything else are really
different between users and contributors it will be better to track them
separately.
--
Ticket URL: <https://fedorahosted.org/council/ticket/16>
council <https://fedorahosted.org/council>
Fedora Project Board Public Tickets

#42: Schedule a FLOCK Budget Planning Session w/Council
-------------------------+-------------------------------------------------
Reporter: decause | Owner: decause
Status: new | Priority: minor
Component: Board Meta | Keywords: FLOCK, session, budget, council,
| fiscal,
-------------------------+-------------------------------------------------
As per our discussion about Budget Planning here,
(https://lists.fedoraproject.org/pipermail/council-
discuss/2015-October/013742.html) one conclusion we came to was that
Budget Planning for the next fiscal year would begin during August at
FLOCK with a high-bandwidth in person meeting, that continued on maillists
and IRC through September, and was delivered to the FCL in October, to be
presented to Red Hat via OSAS.
This ticket is a reminder that we need to schedule a session at FLOCK for
the high-bandwidth in person session.
--
Ticket URL: <https://fedorahosted.org/council/ticket/42>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#49: Decision FUDCon APAC 2016
---------------------+-------------------
Reporter: gnokii | Owner:
Status: new | Priority: normal
Component: General | Keywords:
---------------------+-------------------
following a conversation with Matthew I write this ticket:
The rules for choose a place to holding FUDCons says, that FAmSCo and
Board or now Council have to agree to the recommendation the local
Ambassadors do.
Until yet I only saw more questions which are answered and following that
a discussion, if we should keep FUDCon.
Please, keep in mind how that might look to the bidders, its already the
second time the cambodian community did a bid, when instead of a decision
a discussion comes up to wipe it out. It might look to this community that
we not want it there and we dont want cambodians in our community.
We already lost 2 months where a clear statement would have the local
community enabled to work on making a successful FUDCon 2016.
It is legitimate to discuss if FUDCon is still needed in the regions but
have an eye that the bid means there putting people work and effort into
it, especially in this case as there was a lot of requirements the indian
community wanted to see before agree to the bid.
So please go on and make a decision, to give the local community a chance
to work on it.
https://fedoraproject.org/wiki/FUDCon:Bid_for_PhnomPenh_2016
--
Ticket URL: <https://fedorahosted.org/council/ticket/49>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#38: Dopr
------------------------+-------------------
Reporter: msuchy | Owner:
Status: new | Priority: normal
Component: Trademarks | Keywords:
------------------------+-------------------
Hi,
we (as Copr team) would like to introduce new service "DOPR".
It is very easy. It combine user Dockerfile and user's Copr and create new
docker image on DockerHub.
You can see staging instance at:
http://dopr-dev.cloud.fedoraproject.org/
We would like to start production instance. However some members of
fedora-infra would like to see this go through Council first.
There is some sense on this as this is kind of new way of distribution of
Fedora (beside Spins, Remixs...).
It creates all docker images directly on DockerHub so technically speaking
they are not created in Fedora infrastructure, but they are created under
Fedora account.
And we would like to market it as "Fedorea + Copr" or similar.
So my question: Does Fedora Council approve granting trademark usage on
resulting docker images?
--
Ticket URL: <https://fedorahosted.org/council/ticket/38>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#45: Sponsorship/Funding for FAD EMEA BUDAPEST 2015
---------------------+--------------------
Reporter: rgeri77 | Owner: decause
Status: new | Priority: normal
Component: General | Keywords:
---------------------+--------------------
In this year we would like to organise, and run for FAD EMEA BUD 2015. We
have made our calculations, and we have the venue places, but we require
full funding/cover for food and hotel costs. NOT REIMBURSEMENT. More about
the details can be found at here:
Wiki: https://fedoraproject.org/wiki/FAD_Budapest_2015_bid. The event is
planned to be held at 2015. nov. 27-29.
Budget sheet :
https://docs.google.com/spreadsheets/d/1wl5YcHQOlcM6BeRludN9eq1iTKkbfp2HI...
We have less and less time to have confirmation for the venues, and the
current date that we can hold the offers are 2015 oct. 25. After this date
the hotel cancel the reservation, and give other price (I guess
expensive), so as the conference room owner.
--
Ticket URL: <https://fedorahosted.org/council/ticket/45>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

#48: Trademark approval for unixstickers.com
------------------------+-------------------
Reporter: mattdm | Owner:
Status: new | Priority: normal
Component: Trademarks | Keywords:
------------------------+-------------------
http://www.unixstickers.com/ has asked for trademark permission to make
Fedora stickers. In return, they'll provide us with a supply of branded
items at no cost to us to distribute at events like Flock and FUDCon.
They've actually been asking for a few _years_, and over the past several
months, Tom Callaway has worked with Red Hat Legal to create a contract
which Fedora Legal, RH Legal, and unixstickers all feel good about. (I can
provide council members a copy if you care; it's... you know, legal
stuff.)
And Máirín Duffy has worked (significantly, as I understand it) to make
sure the designs are correct and up to brand standards. Spot also says
that he has samples and the quality is very high. Right now, they've only
discussed stickers, but the vendor has a wide range of merchandise which
could be an option in the future.
Since trademark decisions are important, we need full consensus: at least
3 +1s and no -1s. Let's do that by the end of the week (Friday, December
11th).
--
Ticket URL: <https://fedorahosted.org/council/ticket/48>
council <https://fedorahosted.org/council>
Fedora Council Public Tickets

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please keep responses on the devel@ list. CCed to the Council list for
visibility and discussion of how this fits with our "Freedom" foundation.
== Premise ==
Some upstream distribute tarballs that include code and content that
has been generated at distribution time. Some (non-exhaustive)
examples of this include:
* Code produced by gdbus-codegen
* Code generated by a YACC implementation such as bison or jison.
* Autotools scripts such as libtool
* Man-pages that are built from templates such as Docbook.
* Minified JavaScript or CSS
There are many other examples, but those are readily called to mind.
This brings up several important questions:
1) Do we require that the original data used to generate this code is
included in the SRPM?
2) Do we require that whatever tools are necessary to generate this
code is packaged in Fedora (with all the legal and policy requirements
that this implies)? If we do not, do we require that the code used by
upstream is free software?
3) Do we require that building in Fedora always requires regeneration
of this code from the original data?
== Analysis ==
Shipping pre-generated content may introduce risk:
* If the pre-generated code produces code that is not human-readable,
it may be impossible to audit (or verify that it actually matches the
input files, if available). For example, a compromised upstream might
be shipping a back-door, possibly without knowing.
* If a bug or security vulnerability is discovered in the generated
code, will it be reasonable for a Fedora maintainer to patch it?
Patching the source files vs. patching the generated output can be a
very significant difference in the level of effort.
* Code that was pre-generated by upstream may have been done with
build flags that differ from Fedora's own set of hardened and
optimized flags, resulting in a poorer experience (or less secure
Forcing the re-generation of all such code may be infeasible in many
cases. For example, the call has gone out numerous times in the past
to mandate that `autoreconf` must be run on all autotools code (to
enforce compiler flags) and every time it has been defeated because
many programs won't generate with anything but the version of
autotools that was used by upstream (which is a separate problem).
FESCo discussed this very briefly in our last meeting, but it was
decided that we should open this up to community discussion before
attempting to make a decision. Please add your thoughts to this thread
and FESCo will revisit it at our next meeting (after the New Year).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZ0Wu8ACgkQeiVVYja6o6PYCgCfZ60GH/PYiDqlZzPX38XEAhMI
97UAn2kBrPcbOvdjK2sYkwFCiO/dzXwu
=ge2Z
-----END PGP SIGNATURE-----