Previous attempt of APE 11 (#14) sat languishing for almost 8 years and was rejected in the end (see #14 (comment)). If enough interest and bandwidth return, might worth revisiting.

This essentially requires us to always find someone outside the astropy project, because all members that are deeply involved will be voting members. Alternatively, one member must abstain from voting, just to be able to be the returns officer.

I get the motivation for requiring the returns officer to be non-voting (don't want that person to meddle with the votes since no one else is looking), but

• a technical solution such as helios would make the return's officer's vote just as anonymous as all other votes and that person (depending on the technical platform used for voting) would not have any special knowledge either
• just the requirement to be "non-voting" does not mean the returns officer is not conflicted e.g. they might really like or dislike some candidate. If this provision is meant to prevent tampering with the votes, that "non-voting" is not enough, we need a "not involved" returns officer.

So, I suggest to either remove the "non-voting" requirement to change it to "who cannot be a voting member and not have personally ties to any candidate".

What is the order of axes in pixel_shape and pixel_bounds?
I suggest Cartesian or FITS order, i.e. xyz .

For instance, when are we dropping Python 3.6? Is astropy 5.0 a reasonable release to do so? Where will such decision be documented? Asking for astropy/astropy#10662 .

For that matter, where do we document plans to bump minversions for all the required dependencies for astropy? See https://github.com/astropy/astropy/blob/fecb178391f94eb69eecd67b82d9e00323072719/setup.cfg#L31-L34

Dropping Python 3.6 allows:

• Better annotation support.
• Usage of module level __getattr__.

I've uploaded an APE to Zenodo as a first test:

https://zenodo.org/record/1038587#.WfX5xkzGzBU

Note that all metadata can be updated, so it's fine if we decide to change things. Questions that came up:

• Upload type: Publication?
• Publication type: Technical note?
• If accepted and revised date disagrees, go with last revised date? (for APEs going forward we will upload on acceptance this is not relevant, but I'm just asking for past APEs)
• For past APEs, if there were revisions post-acceptance, should the GitHub URL for the alternate identifier be the last modified commit rather than merge commit?
• For the title, for anyone who stumbles across these documents in Zenodo, I think it would be clearer to have the title as:

Astropy Proposal for Enhancement: Roadmap for Python 3-only support (APE 10)

instead of

APE 10: Roadmap for Python 3-only support

Do you agree? I'm happy to update the guidelines but just wanted to check all this first.

cc @eteq @bsipocz

There are many links to "Voting Members", with the form

`Voting Members <votingmembers>`_

but the file votingmembers doesn't exist. Has this been moved elsewhere?

From my old notes:

• APE 1 might to be modified/expanded to be applicable for governance (APE 0). For example, “prototype implementation” doesn’t quite make sense for a governance proposal.
• APE 1 does not explain how the “iterative process” to update an existing APE should be done. Also see #58.
• Nice to have: Some sort of decision tree (flowchart) to handle proposals of varying complexity.

I had suggested this as a Coordination meeting topic on astropy/astropy-project#255. But maybe we can save time by simply asking the question: is APE 13 still considered the current guidance on spectroscopy code development, or are substantial revisions needed? Has it been superseded by another document?

I want to be able to point people from outside the Astropy community to that document or its equivalent. These people may be potential contributors to code development, so it's more than just for the purpose of satisfying a passing interest.

As the contributors to APE 13: @kelle @eteq @pllim

APE 14 was recently updated, so we should upload a new version to Zenodo. This is a reminder to figure out who uploaded the original version, and a note that to update the version, the way to do it is to go to the existing record on Zenodo, and click on 'New version', remove the existing file and add a new file, and increment the version number and publication date.

I am trying out an example on APE 6 but I cannot get it to round trip on write/read with Python 3.7.1, Astropy 3.1, and Numpy 1.15.4. I am not sure if there is a policy to ensure APE examples always work, but I am reporting this anyway FWIW.

>>> from astropy.table import Table
>>> from collections import OrderedDict
>>> import astropy.units as u
>>> t = Table([[1, 4], [2, 3]], names=['a', 'b'])
>>> t.meta['keywords'] = OrderedDict([('z_key1', 'val1'), ('a_key2', 'val2')])
>>> t.meta['comments'] = ['Comment 1', 'Comment 2', 'Comment 3']
>>> t['a'].unit = u.m / u.s
>>> t['a'].format = '%5.2f'
>>> t['a'].description = 'Column A'
>>> t['b'].meta = dict(column_meta={'a':1, 'b': 2})
>>> In [13]: t
<Table length=2>
  a     b
m / s
int32 int32
----- -----
 1.00     2
 4.00     3
>>> t.meta
OrderedDict([('keywords',
              OrderedDict([('z_key1', 'val1'), ('a_key2', 'val2')])),
             ('comments', ['Comment 1', 'Comment 2', 'Comment 3'])])
>>> t.write('ztmp.ecsv')
>>> t2 = Table.read('ztmp.ecsv')
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
...\astropy\io\ascii\core.py in _convert_va
ls(self, cols)
    952                 try:
--> 953                     converter_func, converter_type = col.converters[0]
    954                     if not issubclass(converter_type, col.type):

IndexError: list index out of range

During handling of the above exception, another exception occurred:

ValueError                                Traceback (most recent call last)
<ipython-input-15-eb21516157bd> in <module>
----> 1 t2 = Table.read('ztmp.ecsv')

...\astropy\table\table.py in read(cls, *ar
gs, **kwargs)
   2546         # RST table and inserts at the end of the docstring.  DO NOT REM
OVE.
   2547
-> 2548         out = io_registry.read(cls, *args, **kwargs)
   2549         # For some readers (e.g., ascii.ecsv), the returned `out` class
is not
   2550         # guaranteed to be the same as the desired output `cls`.  If so,


...\astropy\io\registry.py in read(cls, for
mat, *args, **kwargs)
    515
    516         reader = get_reader(format, cls)
--> 517         data = reader(*args, **kwargs)
    518
    519         if not isinstance(data, cls):

...\astropy\io\ascii\connect.py in io_read(
format, filename, **kwargs)
     35     from .ui import read
     36     format = re.sub(r'^ascii\.', '', format)
---> 37     return read(filename, format=format, **kwargs)
     38
     39

...\astropy\io\ascii\ui.py in read(table, g
uess, **kwargs)
    402         else:
    403             reader = get_reader(**new_kwargs)
--> 404             dat = reader.read(table)
    405             _read_trace.append({'kwargs': copy.deepcopy(new_kwargs),
    406                                 'Reader': reader.__class__,

...\astropy\io\ascii\core.py in read(self,
table)
   1195         if hasattr(self.header, 'table_meta'):
   1196             self.meta['table'].update(self.header.table_meta)
-> 1197         table = self.outputter(cols, self.meta)
   1198         self.cols = self.header.cols
   1199

...\astropy\io\ascii\ecsv.py in __call__(se
lf, cols, meta)
    190     def __call__(self, cols, meta):
    191         # Convert to a Table with all plain Column subclass columns
--> 192         out = super().__call__(cols, meta)
    193
    194         # If mixin columns exist (based on the special '__mixin_columns_
_'

...\astropy\io\ascii\core.py in __call__(se
lf, cols, meta)
    982         # Sets col.data to numpy array and col.type to io.ascii Type cla
ss (e.g.
    983         # FloatType) for each col.
--> 984         self._convert_vals(cols)
    985
    986         # If there are any values that were filled and tagged with a mas
k bit then this

...\astropy\io\ascii\core.py in _convert_va
ls(self, cols)
    967                     last_err = err
    968                 except IndexError:
--> 969                     raise ValueError('Column {} failed to convert: {}'.f
ormat(col.name, last_err))
    970
    971

ValueError: Column a failed to convert: invalid literal for int() with base 10:
'1.00'

#76 was accepted without updating README. This needs to be fixed. Thanks!

cc @taldcroft and @eteq

@eblur

There has been a fantastic discussion in astropy/astropy#15170 about the adding type hint annotations to Astropy. Given the magnitude of this change, we would probably benefit from an APE that answers questions like:

• To what extent should Astropy be typed? Should we strive for mypy regular mode or aim for mypy strict mode?
• How do we deal with existing mypy errors?
• What is the process for adding type hint annotations to Astropy?
• How would we go about adding mypy to the suite of continuous integration checks?
• How do we ensure that new code is typed?
• Should we require mypy strict mode for all new code or modules?
• How do we deal with dynamically created content? For example, do we add a .pyi type stub file for the individual units in astropy.units?

We could also add some helpful information, like which tools we could start off using. We probably don't want to be overly prescriptive, since the tooling landscape will probably change significantly in a few years.

Example: APE1.rst will be APE00001.rst, or even APE_00001.rst

Motivation: For consistent file ordering on GitHub and ls of source checkout.

Backward compatibility: Symlink to old names or fix names in all links.

Suggested by @Cadair during Astropy Coordination Meeting 2019.

This sentence in APE 18:

Versions of other runtime dependencies released 24 months prior to a non-bugfix release.

I guess I cannot understand what "prior to a non-bugfix release" mean. I need examples.

As of writing this, astropy has this in its setup.cfg and 24 months ago was Nov 2020:

• pyerfa>=2.0 -- This was released in May 2021. 24 months ago includes 1.7.1.1. So, why not 1.7?
• PyYAML>=3.13 -- It is 6.0 now. 3.13 was released in July 2018. Why didn't we bump to 5.4 (released Jan 2021)?
• packaging>=19.0 -- It is 21.3 now. 19.0 was released in Jan 2019. Why didn't we bump to 20.5 (released Nov 2020)?

Do the optional dependencies count as "runtime" dependencies or we only bump as needed?

xref astropy/astropy-tools#177 and astropy/astropy#13930

This is what APE 0 has to say about the number of Coordination Committee members:

https://github.com/astropy/astropy-APEs/blob/master/APE10.rst only covers up to 3.6. But this is still too early but we need to do it eventually when Python 3.8, etc comes out.

As proposed by @bnavigator here:

• astropy/astropy#16376

For reference:

• https://numpy.org/neps/nep-0029-deprecation_policy.html (I don't see any deprecation notice here though)
• https://scientific-python.org/specs/spec-0000/

We might want to consider updating APE14 as discussed here:

https://groups.google.com/forum/#!topic/astropy-dev/FPz47h7CH1g

to get rid of pixel_bounds and instead just recommend that NaN values be used in pixel_to_world to indicate places where the WCS is invalid/not well defined.

Please rename your default branch from master to main as part of astropy/astropy-project#151 , preferably by 2021-03-22. Also a friendly reminder to check documentation, workflows, etc., and update them accordingly. Please don't forget to communicate this change to your users and stakeholders. To summarize:

• Rename branch from master to main, preferably by 2021-03-22.
• Update documentation, workflows, etc., accordingly. -- See #67
• Communicate this change to your users and stakeholders.

Once this is taken care of, you may close this issue.

This is an automated issue. If this is opened in error, please let @pllim know!

Would be nice if we have something like

https://github.com/astropy/astropy-tools/blob/main/next_pr_number.py

but for APEs, following:

• #97

However, this script would be more complex given that it needs to find a way to reliably extract "reserved" numbers from all the proposals, past and present, given the inconsistency that have existed for many years.

astropy/astropy#13331 highlighted that the ECSV specification formally allows for flexibility in the marker used to indicate missing data, but there is no way within the ECSV standard to communicate to readers what that marker is.

In particular, the Gaia project has generated ECSV files that use null for missing data. This requires a minor workaround to read with astropy. Reading the Gaia DR3 files with TOPCAT/STILTS is possible since it accepts null for missing values in numeric columns (with a performance penalty in the current implementation), but those null values are passed through normally for string columns.

This issue is intended to discuss options for updating the ECSV specification to provide unambiguous treatment of missing values.

One idea is to add an optional table-level keyword that specifies the string value that signifies missing data. This same optional keyword could also be included in the column keywords to provide per-column specification of the missing data marker for each column.

As mentioned by @taldcroft in #48 (comment) , "But the bigger question of testing APE6 examples is quite good."

1. Find the actual owner of https://zenodo.org/records/4563083 for APE 18. cc @Cadair and @astrofrog as original APE authors.
2. Find a way to transfer it to Astropy Project account.
3. Update the record with #107

This is a result from 2021-08-23 Astropy infrastructure tag-up. Assign this to @mwcraig .

If there is one already it would be good if it were linked to in the readme. If there isn't, there should be (perhaps in the readme, or somewhere else).